通过

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

部署 Azure 登陆区域

本文介绍可帮助你部署平台和应用程序登陆区域的选项。 平台登陆区域提供工作负载使用的集中式服务。 应用程序登陆区域是为工作负载本身部署的环境。

重要

有关平台登陆区域与应用程序登陆区域的定义和实现的详细信息，请参阅什么是 Azure 登陆区域？

选择平台登陆区域方法

以下平台部署选项提供了一个结构化的方法，用于部署和运行Azure 登陆区域概念体系结构，如 Azure 的云采用框架中所述。 生成的体系结构可能因自定义项而异，因此对于本文中列出的所有部署选项来说，该体系结构可能不同。 平台部署选项之间的差异取决于它们使用不同的技术、方法和自定义。

标准部署选项

标准部署选项解决了典型的企业 Azure 使用情况。

Azure 平台登陆区域部署选项 描述
Azure 门户部署 基于 Azure 门户的部署完整实现了 Azure 登陆区域概念体系结构，并为关键组件（例如管理组和策略）提供了预设配置。
Bicep 部署 基于基础结构即代码（IaC）的模块化部署，其中每个 Bicep 模块都封装 了 Azure 登陆区域概念体系结构的核心功能。 这些模块可以单独部署，但设计建议使用业务流程协调程序模块来封装使用模块部署不同拓扑的复杂性。 Bicep 部署支持 Azure 公有云、由世纪互联运营的 Azure 区域，以及美国政府云的 Azure 基础架构服务。
Terraform 部署 基于 IaC 的部署，它使用 Azure 验证的模块来部署平台登陆区域，并提供一种可自定义的方式来使用 Terraform 部署 Azure 登陆区域。

变体和专用化

标准平台部署选项解决了典型的企业 Azure 使用情况，但某些部署选项侧重于特定的专用化。 例如， 主权登陆区域 是 Azure 登陆区域的变体，专为需要高级主权控制的组织而设计。

合作伙伴的实施

Azure Migrate 和现代化等合作伙伴计划可以帮助你设计和实现特定于组织需求的平台登陆区域。 这些实现从 Azure 登陆区域概念体系结构 和设计配置开始，这些配置特定于云采用策略、组织拓扑和所需结果。

企业策略作为策略管理代码

企业策略即代码（EPAC） 是在贵组织的 Azure 资产中部署、管理和运营 Azure Policy 的替代方法。 可以使用 EPAC 而不是 标准平台选项 来管理 Azure 登陆区域环境中的策略。 有关集成方法的详细信息，请参阅 将 EPAC 与 Azure 登陆区域集成。

EPAC 最适合更高级的 DevOps 和 IaC 客户。 但是，任何规模的组织都可以在评估 EPAC 后使用其。 有关详细信息，请参阅 谁应使用 EPAC？。

注意

在决定使用长期的方法之前，请比较这两种方法的生命周期和灵活性。 首先评估 默认实现中的本机策略管理。 如果该实现不符合治理需求，请使用 EPAC 执行 MVP 或概念证明。 请务必在实施方法之前比较选项、验证调查结果并确认选择，因为在建立选项后很难更改策略治理方法。

操作 Azure 登陆区域

部署平台着陆区后，您需要对其进行操作和维护。 有关详细信息，请参阅 使 Azure 登陆区域保持最新。

Azure 治理可视化工具

Azure 治理可视化工具 可帮助你通过联系各个方面并提供精细的报表，全面认识技术 Azure 治理实施。

订阅自动售货

平台登录区域和治理策略到位后，下一步是为工作负荷所有者建立订阅创建和运营的一致流程。 订阅民主化 是 Azure 登陆区域的设计原则，它使用订阅作为管理和规模单元。 这种方法可加速应用程序迁移和新应用程序开发。

订阅销售 标准化平台团队用于工作负荷团队请求订阅和平台团队部署和管理这些订阅的过程。 它允许应用程序团队以一致且受管理的方式访问 Azure，这有助于确保要求收集完成。

组织通常具有各种订阅样式，这些订阅可以出售到其租户中，通常称为 生产线。 有关详细信息，请参阅 创建常见订阅产品线。

若要开始，请按照 订阅自动售货实施指南 进行操作。 然后查看以下 IaC 模块，以便灵活地满足实现需求。

部署选项 描述
Bicep 订阅自动售货 订阅售货 Bicep 模块旨在根据每个工作负荷的配置来协调单个应用程序登陆区域的部署。 它们可以手动执行，也可以作为自动化过程的一部分执行。
Terraform 订订阅自动售货 模块使用 Terraform 协调单个应用程序登陆区域的部署。

应用程序登陆区域体系结构

应用程序着陆区是在一个或多个订阅中指定的区域，专门设置为应用程序团队管理特定工作负载的资源的已批准目的地。 工作负载可以利用平台着陆区的服务，或者选择与这些集中化资源保持隔离。 将应用程序登陆区域用于集中管理的应用程序、应用程序团队拥有的分散工作负载，以及可以托管多个业务部门的应用程序的 Azure Kubernetes 服务（AKS）等集中托管平台。 除非受到异常情况的约束，否则应用程序登陆区域订阅通常仅包含来自单个工作负荷或逻辑应用程序边界的资源，例如其生命周期或关键性分类。

工作负荷团队通过平台团队建立的正式流程来传达其工作负载的要求。 平台团队通常会部署已配置好所有必要治理措施的空白订阅。 然后，工作负荷架构师设计了一个解决方案，该解决方案适用于该应用程序登陆区域的约束，并在实际情况下利用共享平台功能，例如防火墙和跨界路由。

架构师可以将未专门为应用着陆区设计的参考体系结构加以适应。 但是，Microsoft Learn 还为工作负载团队提供了关于应用程序交付区上下文的应用程序和数据平台指南。 让平台团队了解工作负荷团队可用的指南，以便平台团队可以预测组织中可能存在的工作负荷类型和特征。

应用程序登陆区域体系结构 描述
Azure 应用服务环境 经过验证的建议和注意事项适用于多租户和应用服务环境用例，并附有参考实现。
Azure API 管理 关于如何将内部 API 管理实例作为参考实现的一部分进行部署的经过验证的建议和注意事项。 此方案使用 Azure 应用程序网关来帮助提供安全入口控制，并使用 Azure Functions 作为后端。
适用于混合和多云方案的 Azure Arc Azure Arc 启用的服务器、Kubernetes 和 Azure SQL 托管实例指南。
Azure 容器应用 概述战略设计路径并定义用于部署容器应用的目标技术状态的指南。 专用工作负荷团队拥有并运行此平台。
Azure 数据工厂 有关如何在应用程序登陆区域中托管 奖牌湖屋 的指导。
Azure AI Foundry 聊天工作负载 有关如何在 Azure 登陆区域中集成典型 Azure AI Foundry 聊天体系结构 的指南，以使用集中式共享资源，同时遵守治理和成本效益。 它为负责部署和管理的团队提供指导。
AKS 指导和相关 IaC 模板，这些模板表示在应用程序登陆区域中运行的 AKS 部署的战略设计路径和目标技术状态。
Azure Red Hat OpenShift Terraform 模板的开源集合，表示包括 Azure 和 Red Hat 资源的最佳 Azure Red Hat OpenShift 部署。
Azure Synapse Analytics 为 Azure Synapse Analytics 的典型企业部署准备应用程序登陆区域的体系结构方法。
Azure 虚拟桌面 设计 Azure 虚拟桌面部署时应引用的 Azure 资源管理器（ARM）、Bicep 和 Terraform 模板，其中包括创建主机池、网络、存储、监视和加载项。
Azure 虚拟机 从虚拟机基线体系结构扩展到应用程序落地区域的体系结构。 它提供有关订阅设置、修补程序符合性和其他组织治理问题的指南。
Azure VMware 解决方案 可用于帮助设计 Azure VMware 解决方案部署的 ARM、Bicep 和 Terraform 模板。 这些部署包括 Azure VMware 解决方案私有云、跳板机、网络、监控和加载项。
Azure 上的 Citrix 在 Azure 企业级落地区域内，针对 Citrix Cloud 的云采用框架的设计指南，涵盖多个设计领域。
Azure 上的 Red Hat Enterprise Linux （RHEL） 体系结构指南和参考实现建议的开源集合，可用于在 Microsoft Azure 上设计基于 RHEL 的工作负荷。
高性能计算（HPC）工作负载 Azure 中使用 Terraform、Ansible 和 Packer 等工具的端到端 HPC 群集解决方案。 它解决了 Azure 登陆区域最佳做法，其中包括标识实现、跳转盒访问和自动缩放。
任务关键型工作负荷 介绍如何设计任务关键型工作负荷，以在应用程序登陆区域中运行。
SAP 工作负载 为符合 Azure 登陆区域最佳做法的 SAP 工作负荷提供指导和建议。 提供有关如何创建基础结构组件（如计算、网络、存储、监视和 SAP 系统的生成）的建议。

工作负荷通常由各种技术和分类组成。 建议查看工作负载中所有技术的相关参考资料。 例如，了解 Azure OpenAI 聊天和 API 管理中的指南对于确定生成 AI 方案能否从合并 API 网关中获益至关重要。

后续步骤