AzureでCIを始めると、なぜBicepを書き、Azure Verified Modulesを使うのか
連載：Azure Verified Modulesで進めるインフラ標準化・導入編 ｜ 連載のまとめ
開発チームから「別のチームと同じ検証環境が欲しい」と頼まれたとします。必要なのは、パブリックIPを付けないLinux仮想マシン（以下、VM）1台と、手元からVPN経由で接続するためのネットワークです。Azure Portalで作るなら、仮想ネットワークとサブネット、ネットワークインターフェイス（以下、NIC）、VMを作り、接続経路と認証も設定します。次のチームから同じ依頼が来たとき、前回と同じ設定をどこで確かめるでしょうか。
アプリの変更と一緒に、環境の変更もレビューする
アプリのコードを継続的インテグレーション（CI）で検査しても、Azureの設定がポータル操作で変われば、Gitの履歴だけでは環境を再現できません。例えば、本番だけVMの公開IPが有効になった場合、アプリのプルリクエストを見てもその変更は分かりません。
インフラの構成をコードとして管理する方法をInfrastructure as Code（以下、IaC）と呼びます。Bicepでは、Azureに作りたいリソースと設定を書き、環境ごとに異なる値をパラメーターとして渡せます。VMの設定を変えるなら、Bicepとパラメーターの差分をプルリクエストでレビューできます。Azure Pipelinesでは、Bicep Deployタスクを使って検証、変更予測（what-if）、デプロイをパイプラインへ組み込めます。この連載の検証に使ったのはGitHub Actionsです。[1]
一度コードにしても、チームごとに複製すると差が生まれる
最初はVM、NIC、サブネットの参照をBicepに直接書く方法で始められます。次に同じ定義を3チームがコピーし、それぞれが変更すると、例えば次の違いが生まれます。
| 各チームで変わりやすい設定 | 共通化を考える理由 |
|---|---|
| 公開IP、SSH認証、接続先サブネット | ネットワークと認証のルールを揃える |
| VMサイズ、OSディスク、可用性ゾーン | 変更できる項目と標準値を決める |
| 命名、タグ、利用期限 | 管理者が所有者や返却対象を追えるようにする |
自社のBicepモジュールへまとめれば、利用チームは環境名やVMサイズなどの入力を渡す形にできます。Bicepには、モジュールの作成と組織内での共有の仕組みがあります。そこで残るのは、VMや関連リソースを作る共通実装を誰が保守するかです。APIバージョンの更新、既定値の変更、テスト、文書の修正は、モジュールを利用するチームが増えるほど影響範囲も広がります。[2]
汎用の部品に任せることと、自社で決めること
Azure Verified Modules（以下、AVM）は、Microsoftが共通の仕様・テスト・文書の基準を整えているIaCモジュール群です。BicepとTerraform向けに用意されており、この連載ではBicep版を使います。[3]
例えばVPN Gatewayを作るとき、利用側は接続先の仮想ネットワークやSKU、クライアントのアドレス範囲を決めます。検証で使ったAVMでは、Gatewayが使うパブリックIPの作成や内部の参照の組み立てをモジュールに任せられました。自社では、この部品を組み合わせて「VMに公開IPを付けず、利用者はVPNを通ってSSHする」という構成を定めます。
利用者に渡す仕組みまで作るなら、公開鍵をどう受け取り、誰が承認し、何日で返却するかも決めます。毎回書いていたリソース定義を共通部品に移すと、自社の構成、受け入れ試験、利用者への提供に取り組む余地が生まれます。
この例を、筆者はどの順番で確かめたか
- 同じ検証用VMとVPNを想定し、AVMに任せられる実装と、自社で判断する設定を分けました。
- Bicepの直接定義版とAVM版を構築し、展開予測、実際のリソース、VPNとSSHでの接続を比べました。
- 比較したAVM構成を使い、GitHub Issueの申請から承認、接続情報の受け渡しまでを試しました。
- 払い出しが動いた後で、操作権限を専用の枠に絞り、作成と返却が通るかをもう一度確かめました。
この順番で読むと、構成を揃えるためのBicep、部品を再利用するためのAVM、利用者に同じ環境を渡すための自社の仕組みが、一つの例でつながります。各回の読み順は連載案内にまとめています。