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

订阅自动售货

订阅售货提供了一种平台机制,用于以编程方式向需要部署工作负载的应用程序团队颁发订阅。 下图显示了订阅自动售货适合平台和工作负荷生命周期的位置。

显示四个步骤的关系图。

订阅销售基于订阅民主化的概念,并将其应用于应用程序登陆区域。 使用订阅民主化时,订阅(而不是资源组)是工作负荷管理和缩放的主要单元。 有关详细信息,请参阅:

为什么订阅自动售货?

订阅自动售货为需要在 Azure 中部署工作负载的组织提供多项好处。 它标准化并自动执行应用程序登陆区域的请求、部署和管理订阅的过程。 订阅销售简化了订阅创建过程,并将其置于组织的治理之下,因此应用团队可以专注于更自信和更高效地部署其工作负载。

  • 简化流程: 订阅售货为应用程序团队提供请求订阅的官方前门,无需自行导航订阅流程。
  • 提高了速度: 应用程序团队可以更快地访问应用程序登陆区域,并更快地载入工作负载。
  • 高效治理: 平台团队可以通过最少的开销在应用程序登陆区域强制实施治理。

如何实现订阅自动售货

订阅销售涉及三个团队。 云卓越中心(CCoE)建立了业务逻辑和审批流程。 准备就绪后,应用程序团队会发出订阅请求。 平台团队使用请求创建和配置订阅,然后再将订阅移交给应用程序团队。 应用程序团队更新预算、部署工作负荷并建立操作。 以下指南提供有关订阅自动售货过程的每个步骤的更多详细信息。 有关详细信息,请参阅 订阅售货实施指南

显示订阅自动售货过程的关系图。

平台团队可以向应用程序团队提供许多选项和订阅类型。 这些类型称为 生产线 ,因为它们与平台工程原则和做法相关。 有关选择最适合需求的选项的详细信息,请参阅通用订阅自动售货生产线

建立业务逻辑和审批流程

若要实现订阅自动售货模型,需要建立收集基本订阅信息的审批过程。 云卓越中心(CCoE)应计划审批过程,并围绕要收集的信息建立业务规则。

自动执行流程。 应自动执行订阅请求捕获和审批过程,以加快预配和改进合规性。

与现有工具集成。 应将订阅自动售货审批过程集成到现有的 IT 服务管理(ITSM)工具中。 集成可以简化审批过程,减少手动工作,并提高效率,同时减少错误。 它还使维护随时间推移变得更容易,并帮助报告审核的合规性报告。

连接到部署管道。 最佳做法是将审批流程的业务逻辑绑定到平台团队管理的订阅部署管道。 Azure Pipelines 或 GitHub Actions 工作流是订阅部署管道的常见解决方案。

在引入时收集要求。 业务逻辑应允许应用程序团队请求订阅并提供订阅要求。 这些要求应包括预期的预算、订阅所有者、网络预期以及业务关键性和保密性分类。 在流程开始时收集此信息会告知部署参数和利益干系人审批需求。 引入过程还应为平台团队提供足够的信息,以便将工作负荷置于管理组层次结构中。

通过审批过程,应用程序团队可以开始发出订阅请求。

发出订阅请求

订阅售货为应用程序团队请求订阅提供了一个标准流程。 请务必将订阅自动售货的可用性社交化,并确保订阅请求易于进行。 在应用程序团队提交订阅请求后,平台团队将控制该过程。 平台团队在创建订阅并将订阅传递到应用程序团队之前保持控制。

配置网络

订阅自动化需要设置所需的网络组件,并且需要足够灵活,以满足每个应用程序团队的需求。 作为一般指导,切勿在单个路由域中使用重叠的 IP 地址。 如果大小要求发生更改,则可以添加或删除虚拟网络的地址空间,而不会停机。 有关详细信息,请参阅:

使用 IP 地址管理 (IPAM) 工具。 应使用 IPAM 系统并将其集成到售货过程中,以简化 IP 地址分配。 有关详细信息和 IPAM 指南,请参阅IP 地址管理 (IPAM) 工具

授予应用团队自主性。 应向应用程序团队授予在订阅中创建子网甚至某些虚拟网络的权限。 平台团队应始终创建与中心中心对等互连的虚拟网络。

强制实施网络治理。 平台团队应通过分配给管理组层次结构或 (2) Azure 虚拟网络 管理器和安全管理员规则的 Azure 策略强制实施虚拟网络治理。 有关详细信息,请参阅 策略驱动的治理 以及如何 阻止高风险端口

确定订阅放置

平台团队应使用网络和治理要求将订阅置于管理组层次结构中。 在创建订阅之前,它们还应查看订阅配额限制。 有关详细信息,请参阅 定制 Azure 登陆区域体系结构以满足要求

确定正确的管理组。 管理组可帮助你组织和管理订阅和工作负荷部署。 找到或创建一个管理组,该管理组强制实施每个工作负荷的分类和需求所需的策略。

构建灵活的自动化。 自动化应足够灵活(1)来部署多个订阅,并且(2)适合订阅服务限制。

  • 多个订阅: 某些工作负荷需要多个订阅。 例如,某些工作负荷有多个实例,这些实例由订阅分隔。 或者,每个客户使用专用资源的 SaaS 体系结构通常使用数十个订阅。

  • 订阅服务限制: 拥有数千个订阅的企业应具有可部署到旧订阅或将工作负荷共置到订阅中的自动化,以避免这些限制。 有关详细信息,请参阅 Azure 登陆区域常见问题解答

    预配后,可以使用Azure 门户手动请求增加配额。 如果使用可用的 API 自动执行此过程,则更加轻松。 但是,配额请求可能会失败,因此应运行脚本来处理任何错误。 有关详细信息,请参阅 Microsoft.CapacityMicrosoft.QuotaMicrosoft.Support

创建和配置订阅

现在可以创建和配置请求的订阅。 目标是创建一个可重复的、一致的过程。 尽可能多地自动执行订阅创建和配置过程。

使用基础结构即代码 (IaC)。 订阅自动售货的常见策略是使用 IaC 以编程方式创建和配置订阅。 需要商业协议以编程方式创建 Azure 订阅,但无需商业协议即可自动执行订阅配置的各个方面。 有关详细信息,请参阅:

例如,订阅自动售货 BicepTerraform 模块可帮助你采用订阅自动售货模型,而不考虑在商业协议中注册。 应使用 GitHub 操作或 Azure Pipelines 来协调自动化。

使用标记进行成本管理。 在Microsoft成本管理中,应自动将标记分配给每个订阅以实现成本管理和报告目的的一致分配。 虽然你收到了商业协议的计费报告,但成本管理提供了更大的功能。 例如,可以为具有特定标记的订阅创建报表。 有关详细信息,请参阅 如何在成本和使用情况数据 中使用标记,以及 使用标记继承对成本进行分组和分配成本

使用生产订阅和非生产订阅。 在新订阅的请求中,必须指定工作负荷是用于生产还是开发测试。 开发测试环境会导致资源费用降低,但具有其他 条款。 请注意,开发测试产品/服务不适用于 MPA。 有关详细信息,请参阅:

设置标识和基于角色的访问控制(RBAC)。 管理对 Azure 订阅中资源的访问对于维护安全且合规的环境至关重要。 若要控制访问,必须设置标识和 RBAC。 此设置涉及指定订阅所有者、创建Microsoft Entra 组来管理访问权限,以及建立用于部署工作负荷的自动化帐户。

  • 指定订阅所有者。 订阅自动售货自动化需要在创建时指定订阅所有者。 订阅请求应在接收时捕获此信息。 订阅所有者只能是所选订阅目录中的用户或服务主体。 无法选择来宾目录用户。 如果选择服务主体,请输入其应用 ID。

  • 创建Microsoft Entra 组。 除了订阅所有者,还应确保自动售货过程使用Microsoft Entra 组结构来管理对订阅的访问权限。 对于提升(例如写入)访问权限,我们建议对组使用 PIM。 自动执行此创建过程不应违反最佳做法,例如限制订阅所有者数量并使用最低所需的访问权限级别。

  • 建立工作负荷标识。 用于工作负荷部署的工作负荷标识(服务原则)通常在订阅范围内具有提升的权限。 订阅请求过程应在引入时收集工作负荷标识需求。 你的售货过程应创建这些标识并分配适当的订阅访问权限。 请务必注意,工作负荷标识无法使用 PIM 并接收对资源的永久访问权限。 建议使用托管标识来避免管理机密。 有关详细信息,请参阅 标识设计区域

移交给应用程序团队。 平台团队创建订阅后,应将订阅移交给应用程序团队。

更新订阅预算

平台和工作负荷团队共同负责订阅的财务运行状况。 部署应根据订阅请求中的信息创建订阅预算。 应用程序应更新预算以满足其收到订阅时的需求。 预算对于根据当前使用情况和预测使用情况审核支出很有用,但它们并非硬性限制。 如果工作负荷即将超过预算阈值,则应创建预算警报来通知订阅所有者。 对于共享服务(如API 管理),请考虑使用 Azure 成本分配规则在使用订阅之间重新分配成本。

部署工作负荷并运行

应用程序团队应具有自主性,以创建工作负荷和管理操作所需的资源。 平台团队仍负责订阅治理。 随着工作负荷的治理要求发生变化,平台团队应将订阅移动到最能满足工作负荷需求的管理组。 可以使用 Bicep 或 Terraform 自动执行移动。 有关详细信息,请参阅:

后续步骤

查看可向应用程序团队出售的订阅或生产线。 建立一个很好的起点,以便你可以迎合许多不同的方案。