通过

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

有关使用基础结构即代码的建议

  • 项目

适用于此 Azure Well-Architected 框架卓越运营清单建议：

OE：05 使用标准化基础结构即代码 (IaC) 方法准备资源及其配置。 与其他代码一样，使用一致的样式、适当的模块化和质量保证设计 IaC。 如果可能，首选声明性方法。

本指南介绍使用 IaC 作为基础结构部署标准的建议。 使用 IaC 可将基础结构部署和管理集成到现有软件开发实践中。 它为工作负载的所有组件提供一致的标准开发和部署方法。 依赖手动部署会使工作负载面临配置不一致和设计可能不安全的风险。

定义

术语 定义
声明性工具 一类工具，用于定义部署的最终状态，并依赖系统来确定如何部署资源以匹配定义的最终状态。
不可变的基础结构 旨在替换为新基础结构的基础结构，该基础结构在每次部署时运行新配置。 不得就地更改。
命令性工具 列出导致所需结束状态的执行步骤的工具类别。
模块 用于划分资源组以简化复杂部署的抽象单元。
可变基础结构 要就地更改的基础结构。 部署会更改基础结构的配置，而不是将其替换为新的基础结构。

关键设计策略

如 供应链 和 标准化工具和流程 指南中所述，应制定严格的策略来部署基础结构更改， (仅通过代码) 包括配置更改。 应通过持续集成和持续交付 (CI/CD) 管道部署 IaC。 采用这些策略可强制实施所有 IaC 部署流程的一致性，最大程度地降低环境中配置偏移的风险，并确保环境中基础结构的一致性。 此外，还应在风格指南中标准化 IaC 开发和部署工具和流程。 风格指南的建议包括：

首选声明性工具，而不是命令性工具。 与命令性工具相比，声明性工具及其关联的文件是部署和管理 IaC 的更好整体选择。 声明性工具对其定义文件使用更简单的语法，在部署完成后仅定义环境的所需状态。 命令性工具取决于你定义达到所需最终状态所需的步骤，因此文件可能比声明性文件复杂得多。 声明性定义文件还有助于减少维护命令性代码（如部署脚本）的技术债务，这些代码可能会随时间推移而累积。

使用云平台的本机工具，以及本机集成到平台的其他行业经过验证的工具。 云平台提供了使部署 IaC 变得简单明了的工具。 利用这些工具和其他具有本机集成的第三方工具（如 Terraform），而不是开发自己的解决方案。 本机工具受平台支持，并包含满足大多数需求的内置功能。 平台提供商会不断更新它们，随着平台的发展，它们变得更加有用。

注意

请注意，当云提供商和第三方开发人员更新其工具和 API 时，在工作负载中使用最新版本时，可能会遇到意外问题的风险。 在采用新版本的工具和 API 之前，请确保对其进行全面测试。 同样，在部署代码中对工具或 API 调用 时，请避免使用“latest”标志。 有意为工作负载调用最新的已知良好版本。

对特定任务和基础结构类型使用适当的工具。 除了部署之外，基础结构生命周期还涉及多个任务。 例如，需要应用和维护配置，用于编写部署脚本的工具（如 Bicep）可能不是每个管理操作的最佳工具。

同样，为不同的基础结构类型应用所需的状态配置 (DSC) 可能需要不同的工具。 例如，有特定的工具（如 Ansible）用于管理 VM 的 DSC，而 Flux 是用于管理 Kubernetes 群集上的 DSC 的好工具。 平台即服务 (PaaS) 服务可能会为配置管理 (提供不同的工具，例如可通过 IaC 处理的Azure 应用程序配置) 。 软件即服务 (SaaS) 服务可能会受到更多限制，因为它们受到平台的更严格控制。

考虑 IaC 做法范围内的所有任务和基础结构类型，并标准化工具，这些工具可以完成所需的工作，并且可以集成到开发和管理实践中。

脚本和模板应足够灵活，以便轻松部署各种环境。 使用参数、变量和配置文件部署一组标准资源，可修改这些资源以在代码升级堆栈中部署任何环境。 抽象设置，例如资源大小、计数、名称、要部署到的位置以及某些配置设置。 但是，请注意不要抽象太多。 有些设置可以使用参数或变量进行抽象化，这些设置在工作负载生命周期过程中可能不会实际更改，或者可能很少更改。 不应抽象化它们。

注意

避免对不同的环境使用不同的 IaC 资产。 例如，不应为生产和测试环境使用不同的 Terraform 文件。 所有环境都应使用一个文件。 可以根据需要操作该文件以部署到不同的环境中。

对模块的使用进行策略化和标准化。 与参数和变量一样，模块可以使基础结构部署可重复。 但是，请深思熟虑如何使用它们。 标准化抽象策略有助于确保构建模块以满足特定的一致目标。 使用模块封装复杂的配置或资源组合。 如果仅使用资源的默认配置，请避免使用模块。 此外，在开发新模块时要谨慎。 适当时使用维护的开源模块，例如，在非敏感方案中。

记录手动步骤的标准。 可能存在与部署和维护基础结构相关的步骤，这些基础结构特定于你的环境，需要手动干预。 确保尽可能减少这些步骤，并清楚地记录这些步骤。 在风格指南和标准操作过程中，标准化手动步骤，以确保安全且一致地执行任务。

记录处理孤立资源的标准。 根据用于配置管理的工具及其限制，有时工作负荷可能不再需要特定资源，并且 IaC 工具无法自动删除该资源。 例如，假设要从 VM 迁移到某个函数的 PaaS 服务，并且 IaC 工具没有删除已停用资源的逻辑。 如果工作负荷团队不记得手动删除这些资源，这些资源可能会成为孤立资源。 若要处理这些方案，请标准化策略以扫描孤立资源并将其删除。 还需要考虑如何确保模板是最新的。 研究 IaC 工具的限制，了解在这些情况下可能需要规划的内容。

其他 IaC 策略

请考虑以下适用于对工作负载使用 IaC 的建议：

使用分层方法在工作负载堆栈中对齐 IaC 管道。 将 IaC 管道分成多个层有助于管理复杂的环境。 将数十或数百个资源部署为一个整体包效率低下，并可能导致多个问题，例如依赖项损坏。 使用与资源层对齐的多个管道，这些层由其部署生命周期或功能等因素密切相关，因此可以更轻松地管理 IaC 部署。

核心基础结构（如网络资源）很少需要比配置更新更复杂的更改，因此这些资源应构成 低接触 IaC 管道。 你可能有一个或多个用于资源的中触控和高接触 IaC 管道，具体取决于工作负载的复杂性。 以基于 Kubernetes 的应用程序堆栈为例，一个中等触摸层可能由群集、存储资源和数据库服务组成。 高接触层由在持续交付模式下频繁更新的应用程序容器组成。

将 IaC 和应用程序代码视为相同。 将 IaC 项目视为与应用程序代码项目相同，有助于应用相同的严格性来管理所有管道中的代码。 此外，IaC 开发和部署做法应镜像应用程序做法。 版本控制、分支、代码升级和质量的标准应相同。 此外，请考虑将 IaC 资产与应用程序代码资产并置。 这样做有助于确保每次部署都遵循相同的过程，并有助于避免在必要应用程序代码之前无意中部署基础结构等问题，反之亦然。

与组织中的其他团队协作，实现标准化和可重用性。 大型组织有时可以有多个团队开发和支持工作负载。 跨团队协作就标准达成一致有助于重复使用库、模板和模块，从而在工作负载环境中提高效率和一致性。 同样，应在整个组织中标准化 IaC 工具，只要这样做是可行的。

应用“安全性即代码”原则，确保安全性是部署管道的一部分。 在 IaC 开发过程中包括漏洞扫描和配置强化。 扫描 IaC 存储库中公开的密钥和机密。 使用 IaC 的一个优点是，注重安全性的团队成员可以在部署之前查看代码，以确保经安全部门批准发布的配置实际上是部署到生产环境的内容。 有关详细指南，请参阅 保护开发生命周期的建议。

测试例程和非例程活动。 测试部署、配置更新和恢复过程，包括部署回滚过程。

可变基础结构与不可变基础结构

部署可变基础结构与不可变基础结构之间的选择取决于几个因素。 如果工作负荷是业务关键型的，则最好使用不可变基础结构。 同样，如果具有基于 部署标记的成熟基础结构设计，则使用不可变基础结构可能有意义，因为可以可靠地部署应用程序代码和新基础结构。 相反，如果 安全部署做法 规定在出现可误导的部署问题时进行部署是首选选项，则使用可变基础结构可能是更好的选择。 在这种情况下，可能会就地更新基础结构。

注意事项

增加的专用化： 在某些情况下，在工作负载团队中引入新语言伴随着学习曲线，而供应商锁定可能会使它成为一个糟糕的选择。 需要培训团队成员，并根据云提供商的工具支持分析正确的工具。

增加的维护工作量： 需要维护代码库和工具，使 IaC 实现保持最新且安全。 正确跟踪你的技术债务，并培养一种减少债务得到回报的文化。

配置更改时间增加： 使用命令行说明或直接从门户部署基础结构不需要编码时间和/或测试项目。 通过遵循建议的做法（如代码评审和质量保证做法）来最大程度地减少部署时间。

模块化的复杂性增加： 使用更多的模块和参数化会增加调试和记录系统所需的时间，并增加了一层抽象。 平衡模块化的使用，以降低复杂性并避免过度设计。

Azure 简化

Azure 资源管理器模板 (ARM 模板) 和 Bicep 是用于使用声明性语法部署基础结构的 Azure 本机工具。 ARM 模板以 JSON 编写，而 Bicep 是域特定语言。 两者都可以轻松集成到 Azure 管道或GitHub Actions CI/CD 管道中。

Terraform 是 Azure 中完全受支持的另一个声明性 IaC 工具。 它可用于部署和管理基础结构，并可以集成到 CI/CD 管道中。

可以使用 Microsoft Defender for Cloud 发现 IaC 中的错误配置。

示例

有关可通过提供的 资源管理器、Bicep 或 Terraform 文件部署的虚拟桌面实现示例，请参阅 Azure 虚拟桌面登陆区域加速器体系结构和相关参考实现。

卓越运营清单

请参阅完整的建议集。

卓越运营清单