通过

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

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

  • 项目

适用于此 Azure 精心构建的框架卓越运营清单建议：

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

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

定义

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

关键设计策略

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

首选声明性工具而不是命令性工具

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

使用本机和行业标准工具

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

注意

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

为任务使用正确的工具

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

同样，为不同的基础结构类型应用所需的状态配置（DSC）可能需要不同的工具。 例如，有用于管理 VM DSC 的特定工具，而 Flux 是用于管理 Kubernetes 群集上的 DSC 的好工具。 平台即服务（PaaS）服务可能提供不同的配置管理工具（如 Azure 应用程序配置），可通过 IaC 进行处理。 软件即服务（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 的一个优点是，以安全为中心的团队成员可以在部署之前查看代码，以确保通过安全性批准发布的配置实际上是部署到生产环境的配置。 有关详细指导，请参阅 有关保护开发生命周期的建议。

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

采用不可变部署模型

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

注意事项

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

增加维护工作量： 代码库和工具维护需要使 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 虚拟桌面登陆区域加速器体系结构和关联的参考实现。

卓越运营清单

请参阅完整的建议集。

卓越运营清单