Azure Bicep 與 ARM 模板的比較

Question

我讀了一些關於 Azure Bicep 的東西，我覺得這是一種新的東西——

Azure 資源管理器和 ARM 模板是用 JSON 語法編寫的，使用起來可能很麻煩。 Azure Bicep 是一種域特定語言 (DSL)，它提供對 Azure 資源管理器和 ARM 模板的透明抽象，支持更清晰的代碼語法，更好地支持模塊化和代碼重用。 Azure Bicep 為使用 ARM 模板 JSON 創作 Azure IaC 提供了一些改進。

我想了解 ARM 模板和 Azure Bicep 之間的比較，例如這兩者的優缺點、限制和用例。

Answer 1

我認為 Bicep 的官方 GitHub 存儲庫幾乎包含您在問題中提到的所有答案。

部分摘錄：

Bicep 是一種域特定語言 (DSL)，用於以聲明方式部署 Azure 資源。 它旨在通過更簡潔的語法、改進的類型安全性以及更好地支持模塊化和代碼重用來極大地簡化創作體驗。 Bicep 是對 ARM 和 ARM 模板的透明抽象

二頭肌如何讓生活更美好？

• 與等效的 JSON 相比，語法更簡單
• [...]

已知限制

• 不支持單行對象和數組（即 ['a', 'b', 'c']）
• [...]

常問問題

這准備好用於生產了嗎？ 是的。 從 v0.3 開始，Microsoft 支持計划現在支持 Bicep，並且 Bicep 與 ARM 模板可以實現的功能 100% 相同。 在撰寫本文時，目前沒有計划中的重大更改，但將來仍有可能需要進行更改。

更新：更新了摘錄，因為它現在可以生產了。

Answer 2

我認為考慮 BICEP 的最佳方式只是一個更簡單、更不容易出錯的生成 ARM 模板的過程。 最終，BICEP 工具只是一個轉譯器，即將 BICEP 文件轉換為單個 ARM 模板，可以按照您習慣的方式進行部署。 它不會添加額外的抽象層，因此您始終可以使用最新的資源管理器 API 版本和屬性。

玩了一會兒，我對它感到非常興奮。 在 BICEP 出現之前，我使用鏈接模板來實現模塊化並盡可能地重用代碼，但是處理大而冗長的 JSON 文件很麻煩。

有了 VSCode BICEP 擴展以及微軟在 BICEP 的智能感知和 linting 方面所做的努力，加上快速查看 ARM 輸出的能力，我認為我們將享受到顯着的生產力提升。

此外， BICEP 反編譯器看起來是一個非常有用的遷移工具，可以將現有的 ARM 模板轉換為 BICEP。

ARM 模板在過去一直是令人沮喪和痛苦的根源，但 BICEP 是巨大的改進。 顯然 Terraform 在這方面也做得很好，但除非你是專門的多雲和多資源提供商，否則我相信 BICEP 提供了一種明智的方法。

Answer 3

BICEP 比 ARM 模板語法更容易理解。
BICEP 被設計為 Yaml/TS/Js 格式的組合，沒有不必要的標點符號。 Bicep 是一種類似於 CSS 的標記語言，帶有循環、if、三元運算和驗證語法的 VS Code 智能感知插件。 Bicep 仍然需要用戶理解 Azure 資源管理器“資源”（一個 Bicep 術語），但為 devops 猴子提供了比容易出錯的 json jibberish {","} 更甜蜜的語法糖； Bicep 還增加了對不屬於 Json 的評論的支持。 Bicep 與 -c（“檢查健全性”）一起使用也更安全，因為所有內容（默認情況下）都限定在 ResourceGroup 級別。

BICEP 提供與 ARM 相同的功能，因為它是一個轉譯器，可生成 ARM 模板，但添加了更高級別的功能，例如循環、包含、符號引用。 ARM 是二頭肌的底層語言，它也被 terraform 或自我管理的 K8 自動縮放等工具使用。

一個缺點是 BICEP 轉譯為 ARM，所以如果你的二頭肌代碼中有錯誤，你可能最終需要學習 ARM 以了解發生了什么。

Answer 4

一個缺點是 BICEP 轉譯為 ARM，所以如果你的二頭肌代碼中有錯誤，你可能最終需要學習 ARM 以了解發生了什么。

我認為當您遇到 TF 問題時，這個缺點比調試更容易。

目前ARM模板和BICEP的關系是直截了當的，一對一的，非常直白。 不幸的是，使用 Azure 需要了解 Azure REST API 規范和 ARM 模板。 但我喜歡 Bisp 因為我不想每次都和 ARM Tempate 搏斗。

二頭肌讓我的 Azure 生活變得快樂。