はじめに

皆さまこんにちは。ウィズワンダーの中島です。

さて、今回の記事タイトルにもある GitHub Actionsは利用されている方も多いと思います。GitHub Actions は非常に簡単に CI/CD パイプラインを構築することが可能ですが、弊社では Azure をメインに利用していることから、AzureとGitHub Actionsを連携させて使用する構成が多いです。

そこで今回は、GitHub Actionsを使用してコンテナイメージをビルドしたうえでAzure Container Registry (ACR)にPushし、そのイメージを元にAzure Container Appsにリビジョンを作成する、つまりデプロイする方法を解説します。

Container Appsのビルド、デプロイ用Actionについて

Azureが公式で用意しているContainer Appsのビルド、デプロイ用GitHub Actionは下記です。

Azure Container Apps Build and Deploy

上記をご覧いただくと分かりますが、2024年8月19日時点で最新版はv2となっております。

マイクロソフトの公式ドキュメントや、上記 Action の README では v1 が使用されていますが、今回の記事ではazure/container-apps-deploy-action@v2を使って説明いたします。

Azureへのログイン設定

まず、Container Appsのデプロイに必要となる、Azureへのログインについてご説明いたします。Azureへのログインはazure/login@v2のGitHub Actionを利用します。

Azure Login Action

こちらも記事執筆時点でv2系が最新となっておりますので、その前提で説明いたします。こちらをご覧いただくと、ログイン時に指定可能なパラメータが複数あるのがお分かりいただけると思います。今回はAzureのマネージドIDによる認証でログインするようにします。

今回の記事ではACRへのPushやContainer Appsへのデプロイに使用するマネージドIDを作成し、ACRとContainer Appsにそれぞれ RBACで権限を与えます。

マネージドID に RBAC で権限を付与する方法は、弊社の下記の過去記事にて詳しく説明しております。

なお、今回のテーマで必要な権限は以下のとおりです。

ここで重要なのが、Container Apps Envにも権限が必要なことです。この権限がないと、Container Appsへのデプロイで失敗してしまいます。

次に、先ほど作成したマネージドIDのフェデレーション資格情報にアクセスし、’資格情報の追加’を行います。シナリオとして「Azure リソースをデプロイする GitHub Actions」を選択します。これを選択すると、GitHub関連情報を設定する画面になるので、必要な情報を入力します。

フェデレーション資格情報が設定できたら、そのマネージドIDの “クライアントID” と、 “EntraIDのテナントID” を控えます。

そして、下記のようにGitHub Actionsのjobs/stepsに設定します。

  - name: Checkout to the branch
    uses: actions/checkout@v2

  - name: Azure Login
    uses: azure/login@v2
    with:
      client-id: "先程のクライアントID"
      tenant-id: "先程のテナントID"
      subscription-id: "対象のサブスクリプションID"

なお、yamlに各種の値をベタ書きはセキュリティ上好ましくありませんので、GitHubのシークレットとして登録することをおすすめいたします。シークレットの設定方法については、GitHubの公式ドキュメントをご参照ください。

ACRへのPushとContainer Appsへのデプロイ設定

次に、ACRへのPushとContainer Appsへのデプロイを設定していきます。

ACRとContainer Appsの設定は特に難しいことはありません。下記のような形で、ACRの名前やイメージの名前などを指定するだけで、docker buildからpush、Container Appsへの反映までやってくれます。下記の例では、Actionsの起動IDと試行回数をタグ名にしています。

- name: Build and push container image to registry
  uses: azure/container-apps-deploy-action@v2
  with:
    appSourcePath: ${{ github.workspace }}
    acrName: <ACR リソース名>
    containerAppName: <Container App 名>
    resourceGroup: <リソースグループ 名>
    imageToBuild: <ACR リソース名>.azurecr.io/<ACR リポジトリ名>:${{ github.run_id }}.${{ github.run_attempt }}

上記を記述するだけで、GitHub ActionsからContainer Appsへ簡単にデプロイが可能となります。

Container Appsのデプロイ時に指定できるパラメータはこちらに詳細が記載されておりますので、ご確認ください。

また、この方法で新規リビジョンを作成すると、基本的にそれまでのリビジョンの設定内容を引き継いだ上で、参照するイメージのみ変えたリビジョンが作成されます。

必要に応じて、ACRからContainer Appが Pullする際などにマネージドIDによってACR認証を行うことで、よりセキュアな構成が構築できるかと思います。マネージドIDを使用してACRへの認証を行う方法については、弊社のこちらの記事が参考になるかもしれません。

まとめ

今回は、GitHub Actionsを使用してコンテナイメージをAzure Container Registry (ACR)にPushし、そのイメージを元にAzure Container Appsにデプロイする方法をご紹介いたしました。

この方法を用いることで、以下のメリットがあります：

1. 自動化されたCI/CDパイプライン: コードの変更がGitHubにプッシュされると、自動的にビルド、テスト、デプロイのプロセスが開始されます。
2. 一貫性のある環境: コンテナ技術を利用することで、開発環境と本番環境の一貫性を保つことができます。
3. スケーラビリティ: Azure Container Appsを利用することで、アプリケーションの需要に応じて自動的にスケールアップ/ダウンすることができます。
4. セキュリティ: マネージドIDを利用することで、セキュアな認証が可能となります。
5. 効率的なリソース管理: ACRを利用することで、コンテナイメージを効率的に管理することができます。

ただし、この方法を導入する際には以下の点に注意が必要です：

1. 適切な権限設定: マネージドIDに適切な権限を設定することが重要です。最小権限の原則に従い、必要最小限の権限のみを付与するようにしましょう。
2. シークレット管理: GitHub Actionsで使用する各種IDやキーは、適切にシークレットとして管理する必要があります。
3. コスト管理: Azure Container AppsやACRの利用にはコストが発生します。不要なリソースは適切に削除し、コストを最適化しましょう。
4. モニタリングとログ: デプロイ後のアプリケーションの動作を適切にモニタリングし、問題が発生した際に迅速に対応できるようにしておくことが重要です。

GitHub ActionsとAzure Container Appsを組み合わせることで、効率的で信頼性の高いCI/CDパイプラインを構築することができます。この記事がみなさまのデプロイプロセス改善の一助となれば幸いです。

最後に、技術は日々進化しています。本記事の内容も、将来的に変更される可能性がありますので、常に最新の公式ドキュメントをご確認いただくことをおすすめいたします。

弊社のご紹介

弊社ではAzure構築・アドバイザリーサービスを提供しております。

マイクロソフト出身、 Azure 認定資格を保持するエンジニアが Azure に関するアドバイスや、環境構築などのご支援をいたします。

また、マイクロソフトのAzureサポートとのやり取りも弊社にお任せいただけます。
サポート担当とのやり取りは、慣れていない場合適切な情報を引き出すことができず、連絡の往復が続き問題解決までに時間がかかることが多いです。

弊社のアドバイザリーサービスでは、弊社で回答できる部分は迅速に回答し、Azure内部の調査が必要な場合などはAzureサポートと連携して問題解決にあたることができます。

Azure をより活用し、最適な構成を構築するご支援をいたしますので、ご検討の方はお気軽にお問い合わせください。