你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
使用基础结构即代码更新 Azure 登陆区域
本文介绍使用基础结构即代码（IaC）更新 Azure 登陆区域的好处。 组织需要更新其登陆区域，以确保配置正确，并响应更改需求。
IaC 可以管理整个生命周期，并且它擅长管理其部署的资源。 组织应计划使用 IaC 部署其 Azure 登陆区域。 它要求计划将现有非 IaC 资源与状态管理支持的 IaC 资源保持一致。 需要将现有资源映射到所需状态。
有关详细信息，请参阅 使 Azure 登陆区域保持最新。
基础结构即代码的工作原理
IaC 是指使用计算机可读定义文件管理基础结构资源的生命周期的做法和工具。 基础结构的定义是编写、版本控制、通过管道部署的，然后它将成为工作负荷部署的一部分。
IaC 技术是 声明性的，这意味着在 IaC 运行时，它将配置设置为代码中描述的内容，而不考虑其当前状态。 通过脚本（例如 Azure CLI 或 Azure PowerShell）配置基础结构时，它们势在 必行。 命令性脚本执行一组操作，结果取决于当前状态和操作后的状态。
因此，如果有基础结构作为 Azure 资源的代码定义，则可以根据需要运行该定义，并且仅在以下情况下创建更改：
- 定义将更改以添加新资源、删除以前部署的资源或修改以前部署的资源。
- 已部署的资源偏离配置，以将配置重置为定义的配置。
可以使用 IaC 来还原状态，方法是删除不再需要的资源，并通过许多更改管理资源的生命周期。
注意
使用 IaC 删除资源的特定机制会有所不同。 例如，Azure Bicep 需要使用 complete 部署类型来修正范围资源。 此命令仅适用于特定范围。 对于 Terraform，资源具有元 lifecycle 参数，用于说明 Terraform 如何处理资源。
对于 Azure 登陆区域，基础结构即代码有两个主要选项：
- Azure Bicep 是一种特定于域的语言，用于部署 Microsoft 开发的 Azure 资源。 有关详细信息，请参阅 Azure 登陆区域 - Bicep 模块设计注意事项。
- Terraform 是 Hashicorp 生产的产品，用于将基础结构部署到云和本地。 Terraform 具有特定的 Microsoft 为部署 Azure 资源而生成的资源提供程序。 有关详细信息，请参阅 Azure 登陆区域 - Terraform 模块设计注意事项。
使用基础结构即代码更新 ALZ 的好处
以下优势描述了为何应使用基础结构作为代码来更新登陆区域。
减少工作量
与进行手动更改相比，使用基础结构即代码执行更新所需的时间更少。 IaC 部署有助于回答以下问题：
- 当前如何配置资源？
- 此更新将如何配置？
- 将进行哪些更改以使其符合此更新？
当基础结构作为代码工具集运行时，它可以生成更改的比较或“差异”读取。 在将更改提交到环境之前，请查看此读出。
工具集可以编译更改信息，而不是操作员或工程师。
减少错误
由于部署的编程性质，基础结构即代码在进行更改时会减少人为错误。 它仅更改定义的内容，并且具有预览选项，因此可减少由失败或不完整更改导致的中断。 它还改进了测试选项。
版本控制和历史记录
基础结构即代码部署由定义文件提供支持，因此可以使用源代码管理来管理定义的版本。 根据所使用的 IaC 方法，可以引用 Azure 中 Bicep 的部署或 Terraform 的状态文件来查看之前部署的历史记录。
使用源代码管理做法时，它会创建 IaC 的新分支来添加更改和修订。 源代码管理系统中的分支历史记录捕获迭代和更改。 可以使用它将更改部署到测试环境，直到准备好合并更改并将其部署到生产环境。 有关详细信息，请参阅 Azure 登陆区域的测试方法。 在整个周期中，部署记录将捕获已使用的版本和部署的资源，从而提供高度可见的历史记录。
将这些测试方法与 Bicep 配合使用进行常规测试。 使用这些方法，可以在部署代码之前执行测试，并且可以在分支的非生产环境中进行测试。
测试环境
IaC 部署是可重复的，因此可以使用同一定义基于部署部署部署第二个（或更多）环境。 此方法对于测试更改非常有用。
例如，如果要使用 高级版 SKU 替换Azure 防火墙，则可以部署测试环境并验证更改而不更改生产。
捕获配置偏移
IaC 提供了在更新期间捕获配置偏移的唯一选项。 部署捕获对定义文件的更改，并显示资源配置与定义不同的实例。
使用 IaC 的登陆区域更新可帮助你捕获此配置偏移，并允许你适当地更新代码、通过更新解决这些错误配置，或以其他方式解决这些错误配置。
通过门户、CLI 或非 IaC 方法更改资源时，将实现更改。 下次通过 IaC 运行部署时，它将使用 what-if 或计划函数标记代码定义状态与门户中的实际状态之间的比较。 使用此方法确定环境是否在代码文件之外修改。
标识错误后，可以运行 IaC 以尝试使部署与定义保持一致。 使用此方法根据问题的性质、运行的性质以及更改的方式来确定问题和修正方案。 例如，Terraform 尝试将基线还原到已部署的资源，Bicep Complete 中的模式部署会删除不属于定义的资源组中的资源。 这些工具检测和修复配置偏移，但它们可能无法解决所有问题。
有关详细信息，请参阅 带外更改 以及 检测和管理 Terraform 的偏移。
门户中定义的更改很麻烦，无法重新实现到 IaC。 必须更新代码以匹配当前状态，这通常涉及查看每个资源更改并更新其参数以匹配“原样”配置。
如果使用 IaC 管理登陆区域或其他资源，则仅应在 IaC 外部进行更改，作为紧急状态的一部分。 对有权直接进行更改的帐户采取预防措施，例如 Privileged Identity Management。
请参阅以下文章中的常规自动化和安全做法：
后续步骤
浏览以下文章中的 IaC 工具简介：