你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
基础结构即代码（IaC）是一项关键的 DevOps 实践，涉及在描述性模型中管理基础结构，例如网络、计算服务、数据库、存储和连接拓扑。 IaC 允许团队更快、更自信地开发和发布更改。 IaC 的优点包括：
- 提高对部署的信心
- 能够管理多个环境
- 改进了对基础结构状态的理解
有关使用基础结构即代码的好处的详细信息，请参阅 可重复基础结构。
工具
实现基础结构即代码时，可以使用两种方法。
- 命令性基础结构即代码 涉及使用 Bash 或 PowerShell 等语言编写脚本。 明确表达用于实现所需结果的命令。 使用命令性部署时，由你负责管理依赖项、错误控制和资源更新的顺序。
- 声明性基础结构即代码 涉及编写定义你希望环境的外观的定义。 在此定义中，您需要指定希望达到的结果，而不是具体实现的方式。 该工具确定如何通过检查当前状态、将其与目标状态进行比较，然后应用差异来实现结果。
ARM 模板
查看有关 Azure 资源管理器模板（ARM 模板）的信息。
二头肌
Bicep 是一种特定于域的语言 (DSL)，使用声明性语法来部署 Azure 资源。 在 Bicep 文件中，定义要部署的基础结构及其属性。 与 ARM 模板相比，Bicep 文件更易于非开发人员受众读取和写入，因为它们使用简洁的语法。
此示例 Bicep 代码在资源组的区域部署 Azure 存储帐户。 它应用Standard_LRS冗余和 StorageV2 类型。 访问层设置为“热”，用于频繁数据访问。
param ___location string = resourceGroup().___location
param storageAccountName string = 'toylaunch${uniqueString(resourceGroup().id)}'
resource storageAccount 'Microsoft.Storage/storageAccounts@2021-06-01' = {
name: storageAccountName
___location: ___location
sku: {
name: 'Standard_LRS'
}
kind: 'StorageV2'
properties: {
accessTier: 'Hot'
}
}
Terraform
查看有关 Terraform 的信息。
Azure 命令行接口 (CLI)
查看有关 Azure CLI 的信息。
基础结构即代码模块
使用代码部署基础结构的目标之一是避免重复工作或创建多个模板以实现相同或类似目的。 基础结构模块应可重用且灵活，并且应具有明确的用途。
模块是独立的文件，通常包含一组要一起部署的资源。 使用模块可将复杂模板分解为更小、更易于管理的代码集。 可以确保每个模块侧重于特定任务，并且所有模块都可用于多个部署和工作负载。
Bicep 模块
Bicep 允许创建和调用模块。 创建模块后，可以在任何其他 Bicep 模板中使用它们。 高质量的 Bicep 模块应定义多个相关资源。 例如，定义 Azure 函数时，通常会部署特定应用程序、该应用程序的托管计划，以及该应用程序元数据的存储帐户。 这些组件是单独定义的，但它们构成了资源的逻辑分组，因此应考虑将它们一起定义为模块。
Bicep 模块通常使用：
- 用于接受来自调用模块的值的参数。
- 使用输出值来返回结果到调用模块。
- 用于为模块管理的一个或多个基础结构对象定义资源。
发布 Bicep 模块
有多个选项可用于发布和共享 Bicep 模块。
- 公共注册表： 公共模块注册表托管在Microsoft容器注册表（MCR） 中。 其源代码及其包含的模块存储在 GitHub 中。
- 专用注册表： 可以使用 Azure 容器注册表将模块发布到专用注册表。 有关将模块发布到 CI/CD 管道中的注册表的信息，请参阅 Bicep 和 GitHub Actions，或者如果需要， 请参阅 Bicep 和 Azure Pipelines。
- 模板规格： 可以使用 模板规格 发布 Bicep 模块。 模板规范本意是用作完整的模板，但 Bicep 允许你使用模板规范来部署模块。
- 版本控制系统： 可以直接从 GitHub 或 Azure DevOps 等版本控制工具加载模块。
Terraform 模块
使用 Terraform 可以创建和调用模块。 每个 Terraform 配置至少有一个模块，称为其 根模块，由主工作目录中的文件中 .tf 定义的资源组成。 每个模块都可以调用其他模块，这样就可以在主配置文件中包含子模块。 还可以在同一配置或不同配置中多次调用模块。
模块使用所有相同的配置语言概念进行定义。 它们最常使用：
- 用于接受来自调用模块的值的输入变量。
- 使用输出值来返回结果到调用模块。
- 用于为模块管理的一个或多个基础结构对象定义资源。
发布 Terraform 模块
有几种用于发布和共享 Terraform 模块的选项：
- 公共注册表： HashiCorp 有自己的 Terraform 模块注册表，允许用户生成可共享的 Terraform 模块。 Terraform 模块注册表中当前已发布多个 Azure 模块 。
- 专用注册表： 可以将 Terraform 模块无缝发布到专用存储库，例如 Terraform Cloud Private Registry 或 Azure 容器注册表。
- 版本控制系统： 可以直接从 GitHub 等版本控制工具加载专用模块。 有关支持的源的信息，请参阅 Terraform 模块源。
设计注意事项
将登陆区域资源部署到 Azure 时，请考虑使用 IaC。 IaC 完全实现了部署优化，减少了配置工作量，并自动执行整个环境的部署。
确定是否应采用命令性或声明性 IaC 方法。
如果采用命令性方式，则要明确说明要执行的命令，以产生所需的结果。
如果采用声明性方法，请指定所需的结果，而不是希望其完成方式。
请考虑部署范围。 充分了解 Azure 管理级别和层次结构。 每个 IaC 部署必须知道部署 Azure 资源的范围。
确定是否应使用 Azure 本机或 Azure 非本机 IaC 工具。 考虑的要点：
Microsoft完全支持 Azure CLI、ARM 模板和 Bicep 等 Azure 本机工具，从而更快地集成新功能。
非本机工具（如 Terraform）使您能够在多个云提供商（如 AWS 或 GCP）中以代码形式管理基础设施。 但是，新的 Azure 功能可能需要一些时间才能在非原生系统中得到包含。 如果您的组织是多云环境，或者已经使用并精通 Terraform，请考虑使用 Terraform 来部署 Azure 着陆区。
由于模块使你能够将复杂模板分解为较小的代码集，请考虑将 IaC 模块用于通常一起部署的资源。 可以确保每个模块侧重于特定任务，并且可重复使用多个部署和工作负载。
请考虑通过选择公共注册表、专用注册表或 Git 存储库等版本控制系统，为 IaC 模块采用发布策略。
请考虑对 IaC 部署使用 CI/CD 管道。 管道强制实施你设置的可重用过程，以确保部署和 Azure 环境的质量。
设计建议
采用 IaC 方法来部署、管理、管理和支持 Azure 登陆区域部署。
在以下方案中使用适用于 IaC 的 Azure 本机工具：
你只想使用 Azure 原生工具。 你的组织可能有以前的 ARM 或 Bicep 模板部署体验。
你的组织希望立即支持所有 Azure 服务的预览版和 GA 版本。
在以下场景中对 IaC 使用非内置工具：
组织当前使用 Terraform 将基础结构部署到 AWS 或 GCP 等其他云。
组织无需立即支持所有 Azure 服务的预览版和 GA 版本。
使用可重用的 IaC 模块来避免重复工作。 可以跨组织共享模块，以部署多个项目或工作负载并管理不太复杂的代码。
在以下方案中，从公共注册表发布和使用 IaC 模块：
你想要使用已发布到公共注册表的模块来设置 Azure 登陆区域。 有关详细信息，请参阅 Azure 登陆区域 Terraform 模块。
你希望使用由 Microsoft、Terraform 或其他模块提供程序维护、更新和支持的模块。
- 请确保检查你评估的任何模块提供程序的支持声明。
在以下方案中，从专用注册表或版本控制系统发布和使用 IaC 模块：
你想要根据组织要求创建自己的模块。
你想要完全控制所有功能，并维护、更新和发布新版本的模块。
使用 CI/CD 管道部署 IaC 工件，并确保您的部署和 Azure 云环境的质量。