我读到一些关于Azure Bicep的文章，我觉得这是一种新的东西-
Azure资源管理器和ARM模板是用JSON语法编写的，使用起来可能很麻烦。Azure Bicep是一种领域特定语言(DSL)，它在Azure资源管理器和ARM模板上提供了透明的抽象，支持更清洁的代码语法，更好地支持模块化和代码重用。Azure Bicep在使用ARM模板JSON的基础上，为创作Azure IaC提供了一些改进
我想了解ARM模板和Azure Bicep之间的比较，比如这两者的优势和劣势、局限性和用例。
我认为Bicep的官方GitHub存储库几乎有你在问题中提到的所有答案。
部分摘录：
Bicep是一种用于以声明方式部署Azure资源的领域特定语言(DSL)。它旨在通过更干净的语法、改进的类型安全性以及更好地支持模块化和代码重用来大幅简化创作体验。Bicep是对ARM和ARM模板的透明抽象
有了Bicep，生活会更好吗
- 与等效JSON相比，语法更简单
- […]
已知限制
- 不支持单行对象和数组(即[‘a’，‘b’，‘c’])
- […]
常见问题解答
这可以用于生产吗是的。从v0.3开始，Bicep现在得到了微软支持计划的支持，并且Bicep与ARM模板可以实现的功能完全相同。截至本文撰写之时，目前还没有计划进行突破性的更改，但未来仍有可能需要进行这些更改。
更新：更新了摘录，因为它现在已经准备好生产了。
我认为思考BICEP的最佳方式只是一个更简单、不易出错的生成ARM模板的过程。最终，BICEP工具只是一个转发器，即它将BICEP文件转换为一个单一的ARM模板，可以按照您习惯的方式部署。它不添加额外的抽象层，因此您可以始终使用最新的资源管理器API版本和属性。
玩过一点之后，我对它感到非常兴奋。在BICEP出现之前，我使用链接模板进行模块化，并在任何可能的地方重新使用代码，但处理大而冗长的JSON文件很麻烦。
随着VSCode BICEP的扩展，以及微软在BICEP智能感知和linting方面所做的努力，加上快速查看ARM输出的能力，我认为我们将享受显著的生产力提高。
此外，BICEP反编译器看起来是一个非常有用的迁移工具，可以将现有的ARM模板转换为BICEP。
ARM模板在过去一直是令人沮丧和悲伤的根源，但BICEP是一个巨大的进步。显然Terraform在这方面也做得很好，但除非你是专门的多云和多资源提供商，否则我相信BICEP提供了一种明智的方法。
BICEP比ARM模板语法更容易接近
BICEP设计为Yaml/TS/J格式的组合，没有不必要的标点符号。Bicep是一种类似CSS的标记语言，具有循环、if、三元运算和验证语法的VS-Code智能感知插件。Bicep仍然要求用户理解Azure资源管理器"；资源"；(Bicep术语)，但与容易出错的json-jiberish相比，devops monkey有了更甜美的语法糖；Bicep还为那些不属于Json的评论添加了支持。Bicep与它的-c("检查健全性")一起使用也更安全，因为所有内容(默认情况下)都在ResourceGroup级别。
BICEP提供了与ARM的功能奇偶性，因为它是一个生成ARM模板但添加了更高级别功能(如循环、包含、符号引用)的转发器。ARM是二头肌的底层语言，它也被terraform或自管理的K8自动缩放等工具使用。
一个缺点是BICEP可以移植到ARM中，所以如果你的二头肌代码中有错误，你可能最终需要学习ARM来了解发生了什么。
一个缺点是BICEP可以移植到ARM中，所以如果你的二头肌代码中有错误，你可能最终需要学习ARM来了解发生了什么。
我认为当你遇到TF.的问题时，这个缺点比调试更容易
目前，ARM模板和BICEP之间的关系是直接的、一对一的，非常简单。不幸的是，使用Azure需要了解Azure REST API规范和ARM Tempate。但我喜欢Bisp，因为我不想每次都和ARM Tempate摔跤。
Bicep让我的Azure Life快乐起来。
Bicep编译到arm真的很简单。
Bicep的存在是为了增强手臂的创作体验。
没有继续编写Arm模板的用例。