手元で試してから，
Azure へ小さく導入する

必要なもの

手元で試す

開発用の認証（localhost-dev）と，Runner を子プロセスとして起動する local-process ランチャー，ファイルシステムの Certificate Store を使い， 1 台のマシンの上に Conductor と Runner の両方を動かします．ACME は Let's Encrypt の ステージング を使うため，本物の証明書は発行されません．

1. ビルドする

make build    # ./bin/acme-conductor と ./bin/acme-runner
./bin/acme-conductor --version
./bin/acme-runner --version

GHCR のイメージ（イメージとリリース）から始めても構いませんが，Conductor のイメージには Runner が含まれないため，local-process ランチャーを試すにはソースからビルドするか，両方のバイナリを含む独自イメージを用意します．

2. 署名鍵を作る

手元での試用では省略しても動きますが（jobSigning のないローカルランチャーは生の JobSpec を渡します），練習を兼ねて作っておくと Azure デプロイの手順に直結します．

./bin/acme-conductor keygen --private job-signing.pem --public job-signing.pub

3. 設定を書く

deploy/examples/conductor-config.example.json と deploy/examples/runner-config.example.json をコピーして，パスを手元の環境に合わせます．バインディング名（letsencrypt-staging，azure-dns-staging，filesystem-dev）は両方の設定で一致していなければなりません．Conductor はバインディング名しか知らず，実体は Runner 側の設定が持ちます．次は Conductor 側の設定の抜粋です（apiVersion，server，database，scheduler などは例のファイルを参照）．

{
  "executionBindings": {
    "local": {
      "type": "local-process",
      "config": {
        "runnerBinary": "/path/to/bin/acme-runner",
        "runnerConfig": "/path/to/runner-config.json",
        "workDir": "/path/to/conductor-runs"
      }
    }
  },
  "acmeBindings": ["letsencrypt-staging"],
  "dnsBindings": ["azure-dns-staging"],
  "storeBindings": ["filesystem-dev"]
}

Runner 側は storeBindings.filesystem-dev を type: filesystem でファイルシステムの directory に向け，DNS の資格情報が必要なら dnsBindings.azure-dns-staging.passthroughEnv に環境変数名を列挙し，Conductor を起動する側の環境でその変数を export します．

4. Conductor を起動する

./bin/acme-conductor serve --config /path/to/conductor-config.json

既定では 127.0.0.1:8080 で REST API と GUI（/ui/）が動きます．localhost-dev モードでは，ループバックに接続できるローカルユーザーは誰でも管理者として扱われます．

5. ポリシーと target を登録する

docs/conductor.md のセッション例 に沿って，ポリシーを作成し，それを参照する target を作成します．

C=http://127.0.0.1:8080/api/v1alpha1
P=$(curl -s -H 'Content-Type: application/json' \
  -d '{"allowedDnsSuffixes":["example.ac.jp"],"acmeBinding":"letsencrypt-staging","renewBeforeDays":30,"keyType":"ec256"}' \
  $C/policies | jq -r .id)
T=$(curl -s -H 'Content-Type: application/json' \
  -d "{\"fqdn\":\"wiki.example.ac.jp\",\"owner\":\"web-team\",\"policyRef\":\"$P\",\"executionBinding\":\"local\",\"dnsBinding\":\"azure-dns-staging\",\"storeBinding\":\"filesystem-dev\"}" \
  $C/targets | jq -r .id)

target の作成でスケジューラが即座に起こされ，証明書がまだない target は待機中の run になります．次で進み具合を見ます．

6. run を見守る

curl -s $C/targets/$T | jq .lastRun
curl -s "$C/audit?targetId=$T" | jq '.items[].action'

lastRun.status が succeeded になれば，filesystem-dev の directory の下に証明書と秘密鍵が書き込まれています．手動で今すぐ run を要求したい 場合は curl -s -X POST $C/targets/$T/runs を使います（アクティブな run がある間は 409）．GUI（http://127.0.0.1:8080/ui/）でも同じ内容を確認できます．

Azure にデプロイする

同梱の Bicep テンプレート（deploy/azure）は， Container Apps 環境の上に HTTPS ingress を持つ Conductor の Container App と，毎分スケジュール実行される Runner の Container Apps Job，権限の重ならない 2 つのユーザー割り当てマネージド ID，3 つの Azure Files 共有， DNS ゾーンと Key Vault へのロール割り当て，Log Analytics を一括でプロビジョニングします．

まずはステージング CA と 1 つのホスト名から始めてください． このテンプレートは 1 つの組織のサブスクリプションでの staging デプロイでは端から端まで 確認できていますが（同時実行時のリネームの原子性や SMB 上の flock など未確認の項目が残っています．新しい環境へのデプロイは，最初から最後まで見守ってください．

手順

1. 署名鍵ペアを 2 組作る — 交換用共有の往復それぞれに 1 組．
   

   acme-conductor keygen --private job-signing.pem --public job-signing.pub
   acme-runner keygen --private result-signing.pem --public result-signing.pub

   各コマンドが表示する publicKey: の 1 行を，次の手順の設定に貼り付けます．
2. Runner の設定を書く — deploy/examples/runner-config.aca.example.json を出発点にします．lego.stateDir は /state，lego.workDir は /work のままにし，DNS バインディングはマネージド ID で認証するようにします（AZURE_AUTH_METHOD は設定しません．passthroughEnv に AZURE_CLIENT_ID，IDENTITY_ENDPOINT，IDENTITY_HEADER を列挙）．jobSigning.publicKeys は Bicep テンプレートが自動で追加するため，ここには書きません．
3. main.bicepparam をコピーして値を埋める — deploy/azure ディレクトリ内にコピーします（runnerConfigJson の loadTextContent が相対パスで解決するため）．イメージのダイジェスト，バインディング名，DNS ゾーン，Key Vault，公開鍵，OIDC の値を記入します．
   

   cd deploy/azure
   cp main.bicepparam my.bicepparam

4. 秘密鍵を環境変数として export してデプロイする — 秘密鍵は readEnvironmentVariable で読まれ，パラメータファイルには書きません．
   

   export ACME_JOB_SIGNING_PRIVATE_KEY_PEM="$(cat job-signing.pem)"
   export ACME_RESULT_SIGNING_PRIVATE_KEY_PEM="$(cat result-signing.pem)"
   az deployment group create --resource-group rg-acme \
     --template-file main.bicep --parameters my.bicepparam

   イメージはダイジェストで固定して GHCR から直接 pull されるため，ローカルでのビルドや GHCR の資格情報は不要です．
5. 最初の実行を確認する — Runner の設定はデプロイ時には検証されず，各実行の開始時に読み込まれます．待機中のジョブがなくても実行は毎分動き，no pending job; nothing to do で Succeeded になるのが正常です．
   

   az containerapp job execution list -g rg-acme -n <prefix>-runner \
     --query "[0:3].{name:name,status:properties.status}" -o table
   az containerapp job logs show -g rg-acme -n <prefix>-runner \
     --execution <execution name> --container runner --format text

6. GUI のリダイレクト URI を登録する — デプロイ後に出力される conductorGuiRedirectUri（https://<app fqdn>/ui/）を，OIDC プロバイダ側の GUI 用アプリ登録（シングルページアプリケーション）のリダイレクト URI に設定します．アプリの FQDN は初回デプロイ後にはじめて判明するため，これだけを後から登録すればよく，再デプロイは不要です．

実際に組織のサブスクリプションへ 1 つずつコマンドを実行した記録は deploy/azure/walkthrough.md にあります．命名や権限の確認，Entra ID のアプリ登録の作り方まで，順を追って書かれています． 生成 AI（Claude Code など）に作業を手伝わせたい場合は deploy/azure/ai-assisted-deploy.md に，何を AI に任せてよく何を人が判断すべきかがまとめられています．

デプロイ後の運用

イメージとリリース

バージョンタグを打つと，両方のイメージが SBOM と provenance を添えて ghcr.io/cits-nue/acme-conductor と ghcr.io/cits-nue/acme-runner に linux/amd64 と linux/arm64 向けに公開されます．固定する前に リリースを検証し，そのダイジェストで固定して使います．

gh attestation verify oci://ghcr.io/cits-nue/acme-conductor:<version> --owner CITS-NUE
gh attestation verify oci://ghcr.io/cits-nue/acme-runner:<version> --owner CITS-NUE
docker buildx imagetools inspect ghcr.io/cits-nue/acme-conductor:<version>

latest タグも便宜上付きますが，デプロイが固定する対象にはしません．GHCR の公開 イメージにレジストリの資格情報は不要ですが，新しいパッケージ（名前を変えたイメージ，新しい バイナリ）を資格情報なしで pull できるようにするには，組織のオーナーが一度だけ公開設定にする 必要があります．