azure - 有关长期运行的 Azure 部署的指南

Question

我们目前正在开发一组 Bicep 库，作为我们的基础设施即代码总体策略的一部分，虽然需要几分钟才能运行的部署不是问题，但我们必须考虑对长时间运行的任务采取稍微不同的方法。

以 SQL 托管实例为例，部署到虚拟网络可能需要 6 个多小时。应用程序网关可能需要几个小时，应用程序服务环境可能需要 4 个多小时。是否有推荐的方法来在 ARM 或 Bicep 中分离这些长时间运行的任务？提交模板时，Bicep 是否有“不等待结果”选项？

我们考虑过的一种方法是在 DevOps 管道中部署大型基础设施部分，该管道仅在我们需要更改架构时运行，并且以应用程序为中心(应用程序服务、应用程序配置、数据库等)通过以下方式运行不同的 DevOps 管道。

我在 Microsoft 文档(ARM 或 Bicep)网站上看不到任何指导，因此希望得到一些意见。

Answer 1

Bicep 的最佳实践是利用它的依赖图。如果您的应用程序/工作负载需要 10 个资源，那么让 Bicep 管理依赖项，它通常会优化部署顺序并将正确的输入/输出共享到连接的服务。通常，您可以通过调用 main.bicep 来编写此代码，该 main.bicep 随后会引用一堆其他 bicep 文件(模块)来编排部署。

也就是说，当您处理需要花费大量时间来部署的服务(如您所列出的)时，如果您使用我所描述的标准方法，那么您就可以；

1. 通过预先加载所有要紧密连接的服务来加剧“开发人员内部循环”。
2. 这会增加二头肌模块结构的复杂性，您需要确保 ASE 创建不会等待来自 SQL MI 部署的连接字符串。

“Bicep”本身并不关心结果，您甚至可以将 --no-wait 传递给 az deployment group create 命令。然而，ARM 控制平面确实关心，部署失败的影响可能需要重新部署。

考虑到您所谈论的服务，我会将它们视为基础设施基础，并将它们置于另一个管道阶段，该阶段在运行时会有更多条件。然后，您可以在另一个阶段将子资源部署到其中，这是许多 Azure 资源提供程序为子资源提供一流资源类型的好处之一(例如，SQL 数据库作为 SQL Server 的子资源)等)