GitHub Actions for Azure

解決する課題

• GitHub に置いたコードを、プッシュやプルリクエストをきっかけに自動で Azure へデプロイしたい
• デプロイのために長期保管の資格情報（パスワードやシークレット）を持ちたくない
• App Service・Functions・AKS などサービスごとにバラバラな手順を、共通の YAML ワークフローに統一したい
• ビルド・テスト・デプロイの定義を**コードとしてリポジトリで管理（バージョン管理）**したい
• GitHub をソース管理の中心にしたまま、別の CI/CD ツールを増やさずに Azure へ配信したい

主要概念と用語

• GitHub Actions: GitHub に組み込まれた CI/CD 基盤。リポジトリのイベントをきっかけに自動処理を実行する
• ワークフロー（Workflow）: 実行する処理を定義した YAML ファイル。リポジトリの .github/workflows 配下に置く
• ジョブ（Job）/ ステップ（Step）: ワークフロー内の処理単位。ジョブはランナー上で動き、ステップはアクションやコマンドの最小実行単位
• アクション（Action）: 再利用可能な処理部品。Azure は azure/login や azure/webapps-deploy などの公式アクションを提供する
• ランナー（Runner）: ジョブを実行する計算環境。GitHub ホステッドランナーと、自前のセルフホステッドランナーがある
• azure/login アクション: Azure への認証を行う公式アクション。OIDC または資格情報で接続する
• ワークロード ID フェデレーション（OIDC）: GitHub が発行する一時トークンを Azure 側で信頼し、シークレットなしで認証する仕組み
• サービスプリンシパル / マネージド ID: Azure 側でワークフローに権限を割り当てるための ID。OIDC の信頼先として登録する
• GitHub Secrets / Variables: ワークフローに渡す機密値や設定値を安全に保管する仕組み
• 環境（Environment）: GitHub 側のデプロイ先の論理単位。承認やシークレットのスコープを紐づけられる

仕様・制限・クォータ

• 公式アクションが豊富: azure/login、azure/webapps-deploy、azure/functions-action、azure/k8s-deploy、azure/cli など、主要サービス向けのアクションが用意されている
• OIDC 認証に対応: ワークロード ID フェデレーションにより、長期シークレットを保管せずに Azure へ認証できる
• ランナーの選択: GitHub ホステッドランナー（Linux / Windows / macOS）はクリーンな使い捨て環境。社内ネットワーク到達や独自ツールが要る場合はセルフホステッドランナーを使う
• 同時実行と実行時間の上限: 同時に動かせるジョブ数やジョブあたりの最大実行時間にはプランごとの上限がある。長時間ジョブはセルフホステッドが向く
• 無料利用枠と従量課金: パブリックリポジトリと一定枠は無料で、それを超える実行時間が課金対象になる。Azure 側のリソース費用は別途かかる
• 具体的な無料枠・実行時間上限・並列数などは変動するため、最新の公式情報で確認する

内部の仕組み

GitHub Actions for Azure は、独立した別サービスではなく、GitHub Actions のワークフローから Azure へ安全に配信するための公式アクション群と連携の作法を指します。リポジトリの .github/workflows に置いた YAML が、プッシュやプルリクエストなどのイベントをきっかけに実行（Run）として展開され、各ジョブがランナー上で順に処理されます。

認証は azure/login アクションが担います。ワークロード ID フェデレーション（OIDC）を使う場合、ジョブ実行時に GitHub が短命のトークンを発行し、Azure 側に登録したサービスプリンシパルまたはマネージド ID のフェデレーション資格情報がそのトークンを検証します。検証に通るとアクセストークンが払い出され、以降のステップで Azure リソースを操作できます。これにより、長期保管のクライアントシークレットをリポジトリに持つ必要がなくなります。

認証後は、azure/webapps-deploy や azure/functions-action、azure/k8s-deploy などのサービス別アクションが成果物を対象リソースへ配信します。GitHub 側の**環境（Environment）**に承認を設定しておけば、本番反映の直前に人手のゲートを通すこともできます。

設計パターン / ベストプラクティス

• OIDC（ワークロード ID フェデレーション）を既定にする: クライアントシークレットを持たないパスワードレス認証を第一選択にする
• ワークフローは YAML でコード管理し、変更をプルリクエストでレビューしてから反映する
• 環境ごとにワークフローやジョブを分割し、テストに通った成果物だけをステージング・本番へ流す
• 本番環境には承認を設定し、無人デプロイでも人手のゲートを通す
• 公式アクションのバージョンを固定して、意図しない挙動変更を避ける
• キャッシュ（依存パッケージなど）を活用してビルド時間を短縮する
• 権限は最小限にし、ジョブに付与する Azure 側のロールも必要なスコープに絞る

運用・監視

• 各実行のログとジョブ・ステップの状態は GitHub の Actions 画面で確認でき、失敗箇所を追跡できる
• デプロイ先の状態は Azure Monitor / Application Insights など Azure 側の監視で確認し、配信後の挙動を追う
• 失敗時は GitHub の通知（メールや連携）で関係者に知らせ、再実行（Re-run）で復旧を試みる
• ビルドが遅い・詰まるときは同時実行枠やランナーの空き、依存解決やテストのボトルネックを確認する
• セルフホステッドランナーはOS パッチやツール更新、ディスク容量を自分で運用する必要がある

コスト

セキュリティ

• **ワークロード ID フェデレーション（OIDC）**で認証し、長期保管のクライアントシークレットをリポジトリに置かない（AWS の IAM ロール引き受けに近い発想）
• フェデレーション資格情報の信頼条件を絞る: 特定のリポジトリ・ブランチ・環境からのトークンだけを受け付けるよう Azure 側で限定する
• 機密値は GitHub Secretsで保護し、ログに出力されないよう扱う
• 環境の承認で本番デプロイに人手の関門を設け、誤った反映を防ぐ
• Azure 側でワークフローに付与するロールは最小権限にし、デプロイに必要なスコープへ限定する

関連サービス・比較

GitHub Actions for Azure と最もよく比較されるのは、Azure 自身の CI/CD サービスである Azure Pipelines です。どちらも YAML でパイプラインを定義し、ワークロード ID フェデレーションで Azure へ認証できますが、ソース管理や運用画面の置き場所が異なります。

ハンズオン / CLI例

# OIDC 用のサービスプリンシパル（アプリ登録）を作成
az ad app create --display-name "gh-actions-azure"

# アプリにフェデレーション資格情報を追加し、特定リポジトリの main ブランチを信頼
az ad app federated-credential create \
  --id <appId> \
  --parameters '{
    "name": "gh-main",
    "issuer": "https://token.actions.githubusercontent.com",
    "subject": "repo:myorg/myrepo:ref:refs/heads/main",
    "audiences": ["api://AzureADTokenExchange"]
  }'

# サービスプリンシパルにデプロイ先リソースグループへのロールを最小権限で付与
az role assignment create \
  --assignee <appId> \
  --role "Contributor" \
  --scope /subscriptions/<subId>/resourceGroups/<rg>