我们目前正在开发一组Bicep库，作为我们的基础设施的一部分，作为代码整体策略，虽然需要几分钟运行的部署没有问题，但我们必须考虑一种稍微不同的方法来处理长时间运行的任务。
例如，SQL托管示例可能需要6个多小时才能部署到虚拟网络中。应用程序网关可能需要几个小时，应用程序服务环境可能需要4个多小时。是否有推荐的方法来在ARM或Bicep中分离这些长时间运行的任务？提交模板时，Bicep是否有“不等待结果”选项？
我们考虑的一个方法是在DevOps管道中部署大型基础设施部分，该管道仅在我们需要对架构进行更改时运行，并且以应用程序为中心（应用程序服务，应用程序配置，数据库等）通过不同的DevOps管道运行。
我看不到微软文档（ARM或Bicep）网站上的任何指导，因此将感谢一些输入。
1条答案
按热度按时间k5hmc34c1#
Bicep的最佳实践是利用它的依赖图。如果您的应用程序/工作负载需要10个资源，那么让Bicep管理依赖关系，它通常会优化部署顺序，并将正确的输入/输出共享到连接的服务。你通常会通过调用main.bicep来编写它，它随后会引用一堆其他的bicep文件（模块）来编排部署。
也就是说，当您处理需要大量时间来部署的服务时（如您所列），如果您使用我所描述的标准方法，那么您将：
1.通过前端加载所有紧密连接的服务，加剧了“开发人员内部循环”。
1.增加了二头肌模块结构的复杂性，您需要确保ASE的创建不会等待来自SQL MI部署的连接字符串。
“Bicep”本身并不关心结果，您甚至可以将
--no-wait传递给az deployment group create命令。然而ARM控制平面确实关心，部署失败的影响可能需要重新部署。考虑到您谈到的服务，我会将其视为基础设施基础，并将其置于另一个管道阶段，在运行时会有更多的条件限制。然后，您就可以在另一个阶段将子资源部署到它们中，这是许多Azure资源提供者为子资源提供第一类资源类型的好处之一。SQL数据库作为SQL Server的子级，等等）