実務で使えるBicepデプロイ前に確認すべき基本事項
はじめに
最近アサインしている案件で成果物がBicepでAzureのリソースをテンプレートにして提出する必要があり、勉強を始めました。
デプロイする前にデモで検証したり、変更の確認をするための方法でいくつか実務に使えそうなのがあったので自分用にまとめようと思いました。
（補足）Bicep とは
構文チェック
以下のコマンドを実行するとコードの記述が正しいかどうかチェックしてくれます。
bicep build main.bicep
@discription('.... と綴りを故意に間違えました。
その状態で上記のコマンドを叩くと間違いを教えてくれます↓
コードの構文が正しければなにも出力されません。
ベストプラクティス確認
不要な変数や非推奨の設定を検出して教えてくれます。
bicep lint main.bicep
使用していない変数を含む文を最終行に追加して上記コマンドを叩いてみます。
Bicepでは非推奨のdependsOnを追加した場合
Dry Run
誤ったコードを書いて、いきなりAzure上にデプロイしてしまうと
お客様環境に多額のコストがかかったり、誤った挙動や他環境に影響するリスクがあります。
なのでデプロイ前にデプロイ先の変更をシミュレーションする機能がDryRunです。
Bicepの場合 "--what-if" を使用すると変更が確認できるそうです。
New-AzResourceGroupDeployment -Name main -TemplateFile main.bicep -WhatIf
実際にDryRunしてみた
AppServicePlanとAppServiceがデプロイされることが分かります。
この時に、リージョン、SKU、リソース名、プロパティが間違いないか確認します。
（番外編）
Bicepはコマンドを叩いた後一旦、ARMテンプレートに変換するみたいです。
その後Azure Resource Manager（ARM）が変換後の JSON を受け取り、デプロイを実行そうです。
人間が意識する必要はありませんが。
しかし、BicepをARMテンプレートに変換するためのコマンドは用意されているみたいです。
Bicep を ARM テンプレート（JSON）に変換
bicep build main.bicep --outfile main.json
ユースケースが思い当たらないのでCopilotに聞きました。
Ii/CDと相性がいいのは聞いたことが有ります。
が、まだ検討がつかないですね。。
上記を実際に使う機会があればまた、勉強してみようと思います。
さいごに
Iacは自分がずっと実務で扱いたかった分野で、便利さや運用改善を実感してます。
冪等性（べきとうせい）がある環境構築を実現できるということで、
たくさんアウトプットして身に着けていきたいと思いました。
Discussion