BLOGAzureブログ

皆さまこんにちは、SB C&Sの八釼です。
以前にAzureにおけるIaCに関する記事を掲載しましたが、ここで純正ツールとしてARM テンプレートというJSON形式のテンプレートファイルについてご紹介しました。
ただ、この形式のテンプレートを記述しメンテナンスをしていくのは実際にはかなり骨が折れるのです。

そこで今回は、Microsoft社自身もこちらの利用を強く推奨しているARM テンプレートのためのドメイン固有言語 (DSL) 、『 Bicep 』についてご紹介しようと思います。

• 目次
• 1.Bicepとは？
• 2.実際に何がありがたいのか？
• 3.補足
• 4.最後に

Bicepとは？

Azure リソース（環境）のIaCを実現するための❝専用のプログラミング言語❞であり、ARM テンプレートの上位互換に当たるものと考えてもらって差し支えありません。もちろんMicrosoft社純正としての強みも持ち合わせています。

JSON の代わりに Bicep を使用して、Azure Resource Manager テンプレート (ARM テンプレート) を開発できます。 ARM テンプレートを作成するための JSON 構文は冗長になることがあり、複雑な式を必要とします。 Bicep 構文では、その複雑さが軽減され、開発エクスペリエンスが向上します。 Bicep は ARM テンプレート JSON に対する透過的な抽象化であり、JSON テンプレートの機能は一切失われません。 デプロイ中、Bicep CLI により、Bicep ファイルが ARM テンプレート JSON に変換されます。

上記の公式ドキュメントの引用文章にも記載されている通り、より簡単にARM テンプレート開発ができる文章構成ということです。

さらに❝.bicep❞拡張子のファイルにBicepコードを記述した後、そのファイルを使ってそのままデプロイができます。裏側で勝手（自動的）にARM テンプレートファイル（.json）に変換（ビルド）してくれるからです。
逆にAzureはARMテンプレート(JSON)しか読めないため、Azureリソースをデプロイする際にはこのようなコンパイルを行う必要が必ずあるとも言えます。

実際に何がありがたいのか？

詳細な違いについては、以下に記載する公式ドキュメントにおける関連ページを参照いただければと思いますが、一言で言うならば前述したとおりARM テンプレートに比べて作成が簡単です。つまり記述ミスも少なくなり開発スピードも上がります。

公式ドキュメント |  テンプレートにおける JSON と Bicep の比較

ARM ( JSON ) テンプレートは人間にやさしくない

そもそもJSON形式は可読性がそこまで良くなく、選択肢があるのであれば例えばYAMLで記述したいという方も多いと思います。記述量が多くなったり、ネストが深くなると尚更いやに感じると思います。「書きにくく読みにくい」ためです。

大枠でとらえるとここがありがたい

細かくは色々とあるのですが、やはり以下の二点が恩恵が大きいと考えます。

①行数や記述する文字数が減る

JSONファイル（データ）は可読性が良くないことは前述しましたが、そのため人間が読みやすいように整形するのが一般的です。具体的には「改行」と「インデント」を多用します。そのためどうしても行数が多くなってしまうのですが、Bicepで書けば断然少なくてすみます。カンマ( , )やダブルクォーテーション( " )もあまり書く必要性がなくなるので、文字数自体も少なくなることに加え余計なストレスも減ります。

それに加えARMテンプレートの構文に比べ非常に簡素であるというのも、行数や文字数を減らすことに大きく貢献しています。

具体例でみると一目瞭然ですが、例えば以下の画像を見てください。左側がBicepで、右側がJSONです。

②デプロイ失敗確率が低減

JSON 形式でARM テンプレートを記述する場合、依存関係をしっかり記述しなければなりません。つまりリソースAを作成するためにはリソースBの作成が終わってから、みたいな感じです。実際に開発してみると分かりますが、作成の順番が原因でデプロイが失敗することが結構あります。

例えば、VNetがデプロイされていない状態でVMを作成するのは不可能であることが感覚的にわかりますよね？VMをデプロイする際に必ず所属するVNetを指定しなければならないためです。そのため、デプロイの順番をしては必ずVNetの方を先にするように指示しなければならないのです。そんなの仕様上当然なんだからAzure側で上手くやってよって感じなのですが、Bicepならそこを理解してくれて良しなにやってくれるというわけです。

なお、完全に依存関係の記述が不要になるわけではないので、その点は念のためご注意ください。例えば複数のVM拡張機能を単一のVMにデプロイする場合に順番を考慮しなくては上手くいかない場合があります。

単純で簡単な環境であればそれほど苦にはなりませんが、少し複雑なってきたりデプロイするリソースの数が多くなってくると依存関係の考慮はかなり大変です。これについての記述を基本的にしなくて良いことで、①にも貢献できます。

そもそもデプロイが失敗すると、作成した人間としては結構精神的ストレスがかかるものです。このようなストレス発生頻度を低減できるのも有難いところです。

補足

ARM テンプレートのためのDSL

デプロイの際にBicepファイルからARMテンプレートJSONファイルに自動で変換されることは前述しましたが、裏側での処理なので皆さんは基本的には意識しなくても問題はありません。ただ、この事実は知っておくと両社の関係性がより具体的に見えてきます。

つまり、Bicepというプログラミング言語でインフラ構成のソースコードを記述し、それをコンパイルした結果をAzureが読み込んでデプロイを実行できるということなのです。アプリケーションソフトウェア開発の世界と基本的に同じ流れなわけで、クラウドはアプリとインフラの境界線が曖昧と言われる所以が垣間見えますね。
そして、「ARMテンプレートを作成するための言語」がBicepと言えるのではないでしょうか。

ARMテンプレートでの経験は無駄にはならない

既にデプロイされているリソースをテンプレートとしてエクスポートする場合Bicepではないですし、公式のクイックスタートやチュートリアル、GitHubなどで公開されているテンプレートでBicepのものは断然数が少ないです。
つまり、参考にできる情報がまだ少ないというのが唯一の欠点です。しかし、ARMテンプレートの内容が理解できればそれを元にBicepコードに変換することは容易です。

なお、ARMテンプレート(JSON)からBicepファイルに逆コンパイルということもできます。例えば今後Bicepでの運用に切り替えたい場合には、既存のARMテンプレートを変換してしまえば話は簡単そうですね。
ですが話はそう単純ではなく・・・この変換の結果の内容の正確性は保証されておらず、基本的には手直しが必要になります。コードの複雑性にも依りますが、手直しはそれなりに大変です。それぞれの形式をある程度理解していて両社の違いも分かっていたとしても、それなりの時間がかかる場合がほとんどです。ある程度知見がある方でしたら自身（人間の力）での逆コンパイルの方が、早くそして綺麗なコードが書けると個人的には思います。

また、以前にBlueprints（ブループリント）に関する記事を掲載しましたが、アーティファクトとして含めることができるのもBicep コードではなくARMテンプレート(JSON)となります。そのため開発したコードをブループリントで活用するためには、必ずビルドが必要になります。ビルドはデプロイ時に自動で行われるとお伝えしましたが、もちろん手動でコンパイルすることもできます。アーティファクトとして使用するためには、このようにして得たファイルを活用していただければと思います。

このようにARMテンプレートについての基本くらいは最低限知っておかないと困ることが多いので、仮に今後Bicepでの運用に切り替える場合でもそれまでの知見は活きるのでご安心ください。

最後に

BicepはあくまでDSLということでARMテンプレートがなくなるわけではありません。すでにこちらに慣れていらっしゃる方はそのままお使いいただいて全く問題ありません。ただ、Bicepで書いてみるとおそらくARMテンプレートには戻りたくなくなると思います（笑）
これから始める方はBicepが断然おススメです。

弊社では、ユーザー様のご状況やご要望を踏まえて最適な形でのAzureの導入のご支援を提供しており、Bicepに関連するご不明点などにもAzureに精通したスタッフが丁寧にご回答いたします。

今回は細かなことまでは紹介しませんでしたが、実戦で活用するためにはクレデンシャルをハードコーディングしないことやデプロイ実行前の変更のプレビュー、コードの再利用性の向上などなど考慮すべきことが数多くあり、様々なお困りごとが発生するかもしれません。その際にはぜひとも法人でのAzure導入前の相談窓口であるAzure相談センターまでお気軽にお問い合わせいただけますと幸いです。解決の一助となるべく尽力いたします。