🍙

Bicep ファイルの読み方

に公開
Azure
container
Bicep
Aspire
tech

はじめに

Aspireを使って，Azure Container Appsにデプロイした際に，インフラ周りの調整が必要になりました．そういうときは．AspireからBicepファイルの生成ができます．
私はBicepファイルを見たことがなかったので，どのように読んだらいいかを備忘を兼ねてまとめました．

Aspire を Azure Container Apps にデプロイする

前提として，AspireプロジェクトでまとめられているBlazor WebアプリといくつかのバックエンドサーバーをAzure Container Apps にデプロイしました．
MSドキュメントは下記のものを参考にしました．
https://learn.microsoft.com/en-us/dotnet/aspire/deployment/azure/aca-deployment-azd-in-depth?tabs=windows

アプリの構成

             +---------------+
             |    blazor     |  (external=true)
             +-------+-------+
                     |
       calls HTTPS etc.. (internal CAE domain)
                     |
                     |
              +-------------+
              |  backend1   |
              |             |
              +-------------+ 
                (internal)

Bicepファイルの出力

azd config set alpha.infraSynth on
azd infra gen

今回は下記のようなファイル群が出力されました．

infra/
├─ BICEP_README.md
├─ main.bicep
├─ main.parameters.json
├─ acaenv/
│  └─ acaenv.module.bicep
├─ blazor/
│  ├─ blazor.module.bicep
│  └─ blazor.tmpl.bicepparam
└─ backend1/
   ├─ backend1.module.bicep
   └─ backend1.tmpl.bicepparam

📌 ゴール

  • Bicep の基本構成を素早く掴む
  • どの順番で読むか迷わない
  • 複数ファイル（main.bicep と各モジュール）のつながりを理解

1. 全体を読む順番

  1. main.bicep の param を見る（外部入力は何か）
  2. その下の module 呼び出しをざっと見る（部品構造を把握）
  3. 各モジュール（例: blazor.module.bicep など）の param / output だけ先に確認
  4. 必要に応じてモジュール内部の resource 詳細へ
  5. main.bicep の output で最終的に何が返るか確認

2. Bicep の基本構成要素

種類 役割 例
param デプロイ時に外から渡す値 param location string = resourceGroup().location
var 中間計算・再利用用 var tags = { env: 'dev' }
resource 実際に作成される Azure リソース resource stg 'Microsoft.Storage/storageAccounts@2023-01-01' = { ... }
module 別Bicepファイル呼び出し module web './blazor/blazor.module.bicep' = { ... }
output 親へ渡す／表示用 output endpoint string = stg.properties.primaryEndpoints.blob

3. このリポジトリ構成（依存イメージ）

main.bicep
 ├─ module acaenv -> acaenv/acaenv.module.bicep
 ├─ module blazor -> blazor/blazor.module.bicep
 └─ module backend1 -> backend1/backend1.module.bicep
  • パラメータファイル（main.parameters.json）が main.bicep の param に値を供給
  • main.bicep が各モジュールへ params を橋渡し
  • モジュールの output を main や別モジュールで再利用することでサービス間を接続可能

4. モジュールを見るときの着眼点

観点 見る場所 目的
受け取る値 param 上位（main）が何を注入しているか
生成物 resource どの Azure リソース（型 / 名前命名パターン）か
外部提供値 output 他で再利用できる重要な値か（URL, ID 等）
暗黙依存 リソース内参照 別リソースの .id や .properties 参照で自動依存

5. 読解の流れ

[param入力] → [var組立] → [resource定義] → (module呼び出し連鎖) → [output集約]

6. 見かけたらこう読む

パターン 例 意味
文字列補間 '${name}-api' 値を動的組立
既存参照 existing resource vnet ... 既存リソースを参照（新規作成しない）
ループ [for n in range(0,3): { ... }] 複数リソース生成
条件 if (enableFeature) resource feat ... 条件付き作成
依存明示 dependsOn: [otherRes] 通常は参照で足りる（特殊制御時のみ）

7. つまづきポイントと対処

つまづき 原因 対処
どこから読むか迷う モジュール分割 常に main.bicep から開始
依存順序が不安 明示 dependsOn 探しすぎ 参照 = 暗黙依存、自動解決
名前制約エラー 長さ / 文字種制約 エラー文と公式命名規約を確認
値が null になる param 未設定 main.parameters.json を再確認

8. まとめ

  • main.bicep = 全体オーケストレーター
  • param = 外部入力 / var = 中間 / resource = 作るもの / module = 部品化 / output = 結果
  • 依存は参照すれば暗黙的に解決
  • まず「入力とモジュールの関係」を地図化 → 詳細へ潜る

Discussion