使用基础结构即代码部署和管理 Azure 环境

基础结构即代码（IaC）提供用于部署和管理 Azure 资源的编程方法。 它将基础结构预配从手动和容易出错的任务转换为自动化、一致和可重复的部署。

IaC 有助于减少配置偏差，最大程度地减少部署错误，并在整个 Azure 基础结构中建立版本控制。 其编程性质允许团队跟踪更改、回滚部署，并在开发、测试和生产阶段保持一致的环境。

选择基础结构作为代码工具

在 Azure 本机和第三方工具之间进行选择会影响部署功能、支持时间线以及与现有技术堆栈的集成。

1. 为 Azure 优先环境选择 Bicep 和 ARM 模板。 当组织主要关注 Azure 服务时，请使用 Bicep 或 Azure 资源管理器 （ARM） 模板 。 这些工具通常支持早于第三方选项的新 Azure 功能，并与 Azure DevOps、 GitHub Actions 和其他Microsoft开发平台集成。 如果团队已使用 ARM 模板，迁移到 Bicep 可提供改进的语法，同时保持兼容性。 对于新的 Azure 部署，请选择 Bicep 而不是 ARM 模板。 Bicep 提供与 ARM 模板相同的功能，其语法更易于读取、写入和维护。

2. 为多云或现有 Terraform 环境选择 Terraform。 如果组织跨多个云提供商（如 AWS 或 Google Cloud）运行，或者已有 Terraform 专业知识和模块，请使用 Terraform。 尽管 Terraform 通过 AzureRM 提供程序支持 Azure，但新的 Azure 功能可能需要更长的时间才能可用。 Azure 登陆区域 Terraform 模块提供用于部署基础基础结构的企业就绪模板。

3. 了解特定于工具的配置管理注意事项。 每个工具以不同的方式处理配置偏移和带外更改。 Bicep 不维护状态，但可以使用 What-If 和 Azure Policy 支持偏移检测。 Terraform 要求将 带外更改导入 状态文件并更新配置代码。 有关详细信息，请参阅 “管理配置偏移”。

4. 针对特定自动化方案使用命令性工具。 虽然声明性 IaC 工具（如 Bicep 和 Terraform）应该是主要方法， 但 Azure CLI 和 Azure PowerShell 对自定义脚本、具有条件逻辑的复杂工作流或与过程自动化系统的集成非常有用。 这些工具通过提供灵活的脚本选项来补充声明性模板。

使用基础结构作为代码模块

IaC 模块是自包含的代码单元，用于定义要一起部署的特定相关资源集。 此方法可促进代码重用、简化维护，并使团队能够跨部署共享经过验证的模式。 目标是避免复制工作或为类似任务创建多个模板。 开发 Bicep 模块 或 Terraform 模块 ，将复杂模板分解为更小、更易于管理的代码集。 每个模块应侧重于特定任务，并包含要一起部署的资源。

设计 Bicep 模块

Bicep 通过允许创建和重用模块，支持模块化开发。 模块是定义一组相关资源的自包含单元。 创建后，可以从任何其他 Bicep 模板调用模块，促进跨部署的重用和一致性。 设计良好的 Bicep 模块通常会将逻辑上属于同一组的多个资源封装在一起。 Bicep 模块常用：

• 用于接受来自调用模块的值的参数。
• 使用输出值来返回结果到调用模块。
• 资源： 为要管理的模块定义一个或多个基础结构对象。

设计 Terraform 模块

使用 Terraform 模块可以组织和重用基础结构代码。 每个 Terraform 配置都包含一个根模块，其中包含文件中定义的 .tf 资源。 模块可以调用其他模块，包括子模块，并且可以跨配置重复使用。 常见元素包括：

• 用于接受来自调用模块的值的输入变量。
• 使用输出值来返回结果到调用模块。
• 用于为模块管理的一个或多个基础结构对象定义资源。

建立模块发布和分发策略

分发模块的策略会影响协作、版本控制和部署可靠性。 当模块满足要求且受信任的提供程序维护它们时，请使用公共注册表。 对于 Bicep 和 Terraform，Azure 验证模块 提供经过测试和支持的实现，这些实现符合 Azure 最佳做法。 在生产中使用外部模块之前，请始终验证支持和维护承诺。

Bicep 模块发布

可以使用多种方法发布和共享 Bicep 模块：

• 公共注册表 托管在 Microsoft 容器注册表（MCR） 中。
• 使用 Azure 容器注册表（ACR）和 CI/CD 管道实现专用注册表
• 用于存储从 Bicep 模板编译的受版本控制 ARM 模板的模板规格以供重复使用。 它们不是原始 Bicep 模块的注册目录。
• 版本控制系统 （如 GitHub 或 Azure DevOps）用于协作开发，然后通过本地路径 引用 或发布到注册表或模板规格。

Terraform 模块发布

可以通过以下方式发布和共享 Terraform 模块：

• 公共注册表 ，如 HashiCorp 的 Terraform 模块注册表和 Terraform 模块注册表中发布的 Azure 模块 。
• 专用注册表 ，包括 Terraform Cloud Private Registry 或 Azure 容器注册表
• 版本控制系统 ，如 GitHub。 有关支持的源，请参阅 Terraform 模块源。

通过流水线将基础设施以代码形式部署

自动化管道可确保一致且可重复的部署，同时提供可见性并实现快速恢复。

1. 为所有基础设施部署建立 CI/CD 管道。 Azure DevOps 或 GitHub Actions 等平台可帮助自动执行 IaC 部署。 在生产部署之前，管道应包括代码检查、安全扫描、测试和审批门。 它们有助于减少错误，确保一致性，并通过审核线索支持合规性。

2. 通过适当的测试建立环境提升策略。 通过开发、测试、过渡和生产环境部署基础结构，并增加验证。 使用 部署堆栈 或 Terraform 状态管理跟踪资源生命周期并启用安全更新。 实现自动测试，在提升到下一个环境之前，先验证基础结构配置、安全状况和功能。 在将模块集成到更大的部署之前，先单独进行测试。 使用 ARM 模板测试工具包 和 Terratest for Terraform 模块等工具。 建立在发布之前验证模块功能、安全性和合规性的过程。

3. 在部署之前了解部署范围。 查看 Azure 管理级别和层次结构 ，了解需要部署资源的位置。 每个 IaC 模板必须针对适当的范围，不同的工具在每个范围级别具有不同的功能。 例如，租户级部署需要特定权限，并支持与资源组部署不同的资源类型。