你当前正在访问 Microsoft Azure Global Edition 技术文档网站。如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

基础结构即代码

项目
05/23/2023

基础架构即代码 (IaC) 是一项关键的 DevOps 实践，它涉及在描述性模型中管理基础架构，例如网络、计算服务、数据库、存储和连接拓扑。 IaC 允许团队更快、更有信心地开发和发布变更。 IaC 的优势包括：

增强部署信心
管理多个环境的能力
提高对基础设施状态的了解

有关使用基础架构即代码的好处的更多信息，请参阅可重复的基础架构。

工具

在实施基础架构即代码时，你可以采用两种方法。

“命令式基础设施即代码”涉及使用 Bash 或 PowerShell 等语言编写脚本。你明确声明为产生所需结果而执行的命令。当你使用命令式部署时，由你来管理依赖关系、错误控制和资源更新的顺序。
“声明性基础架构即代码”涉及编写一个定义，定义你希望环境的外观。在此定义中，你指定了期望的结果，而不是你希望它如何完成。该工具通过检查你的当前状态，将其与你的目标状态进行比较，然后应用差异来确定如何实现结果。

ARM 模板

查看有关 Azure 资源管理器模板的信息 (ARM 模板) 。

Bicep

Bicep 是一种特定于域的语言 (DSL)，使用声明性语法来部署 Azure 资源。在 Bicep 文件中，你定义要部署的基础设施及其属性。与 ARM 模板相比，Bicep 文件更易于非开发人员阅读和编写，因为它们使用简洁的语法。

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 云专用注册表或 Azure 容器注册表。
版本控制系统：你可以直接从 GitHub 等版本控制工具加载专用模块。有关支持的源的信息，请参阅 Terraform 模块源。

设计注意事项

将登陆区资源部署到 Azure 时考虑使用 IaC。 IaC 全面实现了部署优化，减少了配置工作，实现了整个环境部署的自动化。
确定你应该采用命令式还是声明式 IaC 方法。
- 如果采用命令式方法，请明确说明要执行的命令，以产生你想要的结果。
- 如果采用声明式方法，请指定你想要的结果，而不是你希望如何完成。
考虑部署范围。充分了解 Azure 管理级别和层次结构。每个 IaC 部署都必须知道 Azure 资源的部署范围。
确定应使用 Azure 本机还是 Azure 非本机 IaC 工具。考虑的要点：
- 微软完全支持 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 环境的质量。

通过