规划环境
Azure 资产包含许多组件，包括基本配置、组织范围的资源和设置以及应用程序工作负载。 你可能还会将资产分散到多个环境中，每个环境都有不同的用途。
在本单元中，你将了解在所有部署和配置中一致使用代码的好处。 然后，考虑可能应用于每个环境的控制措施和自动化层级。 你还将考虑更改在部署过程每个阶段的进度，以及支持所选部署策略所需的控制措施和治理类型。
将基础结构定义为代码
Azure 部署和配置涵盖的范围远不止应用程序、虚拟机、存储服务和网络。 例如，以下每一项都是一种配置形式，具有相应的 Azure 资源：
- 创建资源组、订阅和管理组以组织资源。
- 定义和应用 Azure Policy 定义、计划和分配，以控制应如何配置其他资源。
- 分配角色以允许用户、组和工作负载标识访问 Azure 资源。
- 配置监视（包括警报）以观察 Azure 资源并确保它们的行为方式符合预期。
当你首次开始将基础结构定义为代码时，你可能不知道可以在模板或定义中定义的所有项。 但是，随着你对自动化的使用日趋熟练，最好将有关环境的所有内容定义为代码。 为此，可以对所有 Azure 配置使用经过测试和批准的一致流程。 由于在 Git 存储库中对代码进行了版本控制和跟踪，因此你可以查看Azure 环境随时间发生的变化。 可以使用 Git 存储库来跟踪每次更改的历史记录。
例如，假设需要配置 Azure Monitor 警报。 起初，你可能认为使用自动化来部署警报没有意义。 但警报是 Azure 配置的重要组成部分。 如果未正确创建警报，则可能错过关键生产问题的通知。 通过在代码中定义警报：
- 团队成员可以查看警报及其配置。
- 可先将警报部署到非生产环境，以便对其进行测试。
- 对 Azure 配置所做的更改具有完全可跟踪性。
环境
计划自动部署基础结构时，列出计划使用的环境会很有帮助。 许多组织都有多种环境类型，每个类型都有不同的特征。 例如：
- 一些环境运行生产代码，而另一些环境可能使用不同的配置运行同一代码的非生产版本。
- 某些环境生存期较长，永远不会被删除。 其他环境是临时环境：自动创建，并在不再使用时销毁。
- 一些环境由基础结构或软件开发团队使用。 另一些环境由安全团队使用，或者甚至由销售团队在需要向潜在客户展示产品时使用。
请考虑玩具公司可能用于网站的环境：
当你对应用程序或基础结构进行更改并提交更改时，管道会通过一系列非生产环境（开发、测试和暂存）部署你的更改。 你可能还会在某些时候执行手动审批步骤，以便定义的团队成员可以先验证配置或查看管道日志，然后再继续部署。 然后，管道最终会将更改部署到生产环境。
除了这些环境外，销售团队还拥有其自己的演示环境用于与客户交谈。 销售团队采用生产环境的副本来创建其演示环境。 安全和测试团队偶尔会创建生产环境的临时副本，分别用于进行渗透测试和性能测试。
开发团队也有自己的一组环境。 它具有沙盒，供开发团队成员在探索新功能或试验 Azure 服务时使用。 开发团队还为其审查和合并的每个 GitHub 拉取请求创建 PR 审查环境。
受控环境
在其中某些环境中，最好要求使用一个正式过程来审查和应用更改。 这种类型的环境称为受控环境。 应始终控制生产环境。 最好也对某些非生产环境应用控制措施。 这样，可以确保在生产部署之前充分理解和测试控制措施所施加的任何限制。
相比之下，不受控环境没有很多或任何正式控制措施。 它们可能与其他环境具有相同的代码和类似的配置，但它们允许进行更多试验和临时更改配置。 在不受控环境中，用户可以使用 Azure 门户或直接运行 Azure CLI/Azure PowerShell 命令来修改配置。 他们还可以在不使用组织批准的流程的情况下创建资源。 在不受控环境中进行的更改必须先在代码中捕获，然后才能开始应用于生产环境等受控环境。
注意
有时，环境实际上可能表示多个物理环境或部署。 例如，为拉取请求审查创建临时环境时，多个单独的环境可能同时处于活动状态，因为团队提交了多个拉取请求。 但是，出于规划环境的目的，可以将它们视为等效，因为它们具有相同的特征和控制措施。
与团队进行一些讨论后，可以指定哪些环境受控制，哪些环境不受控制。 还可决定谁拥有每个环境。
| 环境名称 | 说明 | 所有者 | 生存期 | 控制级别 |
|---|---|---|---|---|
| 开发 | 将多个开发人员进行的更改集成到单个环境中。 | 运营团队 | 生存期长 | 受控 |
| 测试 | 用于针对更改运行手动和自动测试的环境。 | 运营团队 | 生存期长 | 受控 |
| 过渡 | 在生产之前部署更改的最终非生产环境，其配置类似于生产环境。 | 运营团队 | 生存期长 | 受控 |
| 生产 | 运行生产工作负载。 | 运营团队 | 生存期长 | 受控 |
| 演示 | 由销售团队用于向新客户展示产品。 | 销售团队 | 生存期长 | 不受控 |
| 性能测试 | 动态创建为生产环境的副本，用于运行性能和压力测试，然后在测试完成后删除。 | 测试团队 | 生存期短 | 不受控 |
| 渗透测试 | 动态创建为生产环境的副本，用于运行渗透和安全测试，然后在测试完成后删除。 | 安全团队 | 生存期短 | 不受控 |
| PR 审查 | 为团队成员创建的每个拉取请求动态创建，以更改应用程序或基础结构。 关闭拉取请求时，会删除环境。 | 开发团队 | 生存期短 | 不受控 |
| 开发沙盒 | 由开发团队成员创建，用于进行试验或探索，然后在不再需要时删除。 | 开发团队 | 生存期短 | 不受控 |
前面的环境列表只是一个示例。 在你自己的组织中，需要确定使用的环境、生存期以及每个环境需要的控制级别。
提示
若在部署早期应用这些过程而不是稍后添加它们，则可更轻松地对基础结构代码进行 lint 分析、测试和评审，并且无需修复大量损坏的代码。
同样，如果安全控制从一开始就存在，并且还应用于某些非生产环境，使用它们会容易得多。 这样，你的团队就会习惯于在受控环境中工作。
在整个学习路径中，我们逐步介绍了其中一些概念。 最好尽早将这些元素添加到部署过程中。
隔离每个环境
请务必将每个环境分开，并尽可能使它们独立。 对每个环境使用专用的 Azure 订阅可能会有所帮助，但仍需小心保持环境分离。
避免从一个环境连接到另一个环境。 例如，不要将生产环境的虚拟网络与非生产环境的虚拟网络对等互连。 如果这样做，很容易导致有些用户在非生产环境中意外更改生产数据，或者将敏感的生产数据泄漏到非生产环境。
检查和入口
随着部署过程的进行，应运行一系列检查，以提高你对部署的信心。 你需要确定对进行部署的每个环境有意义的检查。
对基础结构进行的检查通常包括：
- 代码评审。
- 将评审中的代码部署到临时环境，并针对这些环境运行自动或手动测试。
- Lint 分析。
- 预检验证。
- 手动测试。
- 手动审批。
- 自动化功能测试。
- 自动化冒烟测试。
- 等待上一个环境发出的运行状况信号，然后再进入下一个环境。
你可能会在部署过程中多次运行其中一些检查，例如针对每个受控环境。
提示
设计部署过程时，请列出需要执行的所有步骤，无论其多微小或明显。 尽可能详细。 最初你可能不会选择自动执行所有操作，但遵循此做法有助于为将来的自动化部署过程创建蓝图。
入口是必须成功才能继续部署的自动或手动检查。
手动干预
最好在代码评审和部署过程中自动执行尽可能多的检查。 但是，组织可能需要手动批准才能部署到生产或其他受控环境。
如果对部署使用手动审批入口，请遵循以下建议做法：
- 明确定义可以批准部署的人员。 使用 Microsoft Entra 组来定义审批者，而不是指定单个用户。 将来可以轻松更改审批者列表。
- 制定一个紧急部署过程。 计划在标准审批者不可用时可以批准部署的人员。 可能需要在半夜或假期期间进行紧急部署。
- 将人工干预限制为仅批准或拒绝部署。 避免要求人工运行任何部署操作，除非有无法自动执行的步骤。
调控
Azure 提供了可帮助治理环境的工具和功能，包括：
- Azure Policy，用于检测以不符合组织要求的方式配置的资源。 它还有助于防止以导致资源不合规的方式创建或重新配置资源。
- 锁定，用于防止更改或删除重要资源。
- 管理组，可帮助组织 Azure 订阅，并在整个环境中一致地配置基于角色的访问控制和策略。
- Azure Monitor，用于记录资源的指标和日志，将它们显示在仪表板中，并在它们偏离预期值时自动发出警报。
生成 Azure 资产时，请考虑使用 Azure 登陆区域。 通过使用登陆区域，可以从一开始就在环境中生成治理。 许多登陆区域包括预生成的 Bicep 和 Terraform 文件，可帮助配置环境。 在摘要中，我们提供了更多信息的链接。