しばやん雑記

Azure とメイドさんが大好きなフリーランスのプログラマーのブログ

Azure Container Apps の Continuous Deployment 設定が簡単かつ自動生成が適切すぎて感動した話

Azure Container Apps GitHub

この間 Azure Container Apps への自動デプロイの構成を Azure Portal の Continuous deployment から設定したら、予想以上に適切な Workflow ファイルが生成されたことに感動したので書いています。

あまりにも感動したので Twitter にも書きましたが、リポジトリと Dockerfile のパスを指定すれば現時点で最適な Workflow が生成されました。こういった自動生成系は信用していなかったのでかなりの衝撃でした。

最近の Azure では Static Web Apps でもリソース作成時に GitHub のリポジトリとフレームワークのプリセットを選択すれば、自動的に Workflow を生成してくれるようになっていますが、パスフィルターが設定されないので、BYOF を使っている場合でも常にビルドが走ってしまいます。

地味に SWA の GitHub Actions は実行に時間がかかるので、必要ない場合はスキップしたいです。その点 Container Apps が生成する Workflow はパスフィルターが自動で設定されるので、無駄な実行が行われずベストプラクティスに則っていると言えます。

設定自体は以下のように Azure Portal から GitHub にログインしてしまえば、リポジトリの選択と Dockerfile のパスを指定するだけで完了するので非常に簡単です。

注目ポイントはデプロイに必要な Service Principal の自動生成と Container Registry の認証情報を良い感じに扱ってくれることです。自動生成された Service Principal には Container Apps が含まれているリソースグループの Contributor 権限が自動追加されます。最大の Azure はまりポイントなのでありがたいです。

実際に自動生成された Workflow のメインとなる部分を抜粋してきました。設定したのは実質 Dockerfile のパスだけですが、そこから必要なディレクトリを特定してパスフィルターまで設定してくれています。

# When this action will be executed
on:
  # Automatically trigger it when detected changes in repo
  push:
    branches: 
      [ master ]
    paths:
    - 'api/**'
    - '.github/workflows/ctapp-swa-byoa-AutoDeployTrigger-4d143552-044a-419d-b0e1-42832b17f09e.yml'

  # Allow mannually trigger 
  workflow_dispatch:      

jobs:
  build:
    runs-on: ubuntu-latest

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

      - name: Set up Docker Buildx
        uses: docker/setup-buildx-action@v1

      - name: Log in to container registry
        uses: docker/login-action@v1
        with:
          registry: crswabyoatest.azurecr.io
          username: ${{ secrets.CTAPPSWABYOA_REGISTRY_USERNAME }}
          password: ${{ secrets.CTAPPSWABYOA_REGISTRY_PASSWORD }}

      - name: Build and push container image to registry
        uses: docker/build-push-action@v2
        with:
          push: true
          tags: crswabyoatest.azurecr.io/ctapp-swa-byoa:${{ github.sha }}
          file: ./api/Dockerfile
          context: ./api/

GitHub Actions あるあるでパスフィルターを単純に特定のディレクトリだけにすると、Workflow ファイル修正時に起動しなくなって地味に困る件にも最初から対応されていました。

手動で実行したい時に必要な workflow_dispatch*1 も最初から追加されているので文句ありません。

処理自体も build と deploy の 2 ステージに分離されているので管理しやすくなっています。

細かいことを言うと Service Principal は Client Credentials で使うのではなく OpenID Connect で使いたいですし、ACR へのログインは RBAC ベースで実行したいところですが、これまでの自動生成 Workflow と比べるとシンプルで良い定義が生成されています。

OpenID Connect を使って Service Principal を利用する場合は以下のエントリを参照してください。

Static Web Apps が自動生成する Workflow は比較的まともですが、App Service / Azure Functions の Deployment Center から自動生成される Workflow は以下のようにイマイチなので、Container Apps のようにもうちょっと良い Workflow に修正するのが良いです。

そもそも App Service / Azure Functions の Workflow 自動生成は Monorepo に対応していないので、Monorepo の場合は自前での修正は必須です。最低でもパスフィルターは設定しておかないと詰むので注意が必要です。

Web App for Container の Workflow に関しては Container Apps とデプロイ部分以外は全く同じ定義に出来るはずなので、Container Apps をベースにするのも手かなと思いました。

*1:https://docs.github.com/en/actions/managing-workflow-runs/manually-running-a-workflow