ほりひログ

所属組織の製品 (Azure とか) に関連する内容が多めだけど、個人の見解であって、所属組織を代表する公式情報ではないです。

Azure Container Apps のプレビュー用リビジョンを作る GitHub Actions

社内のハッカソン イベントで、Azure Container Apps 関連の GitHub Actions を作った。

Marketplace でも公開中。

github.com

実は、ハッカソン イベントへの参加とは別に、GitHub 上にリポジトリがあることは知っていてウォッチするつもりだったけど、ハッカソン イベントのプロジェクトになっていたので、メンバーに追加してもらった*1

できること

この Action の機能としては 2 つ。
Container App リソースに対して、

  1. コンテナー イメージ名やリビジョン名のサフィックスを指定して、Traffic が 0 のリビジョンを 作成する
  2. 指定したサフィックスを持ったリビジョンを非アクティブにする

ということができる。

Container App のリビジョンについてはコチラのドキュメントをご覧あれ *2

learn.microsoft.com

使い方

想定しているユースケースは、Container App リソースのコンテナーを更新する時に、稼働中のコンテナー/アプリはそのままにして、新しいコンテナーの動作を Container App 上で確認したいケース。

この Action で作ったリビジョンは、イングレスでの Traffic が 0 に設定しておりそのリビジョン専用 URL (Action の出力として取得可能) 経由でのみアクセスができる。
なので、稼働中のアプリへのアクセスには影響を与えずに、プレビュー用途として作ったリビジョンの確認ができる。

例えば Pull Request をトリガーにしたワークフローの中で、新しいコンテナー イメージのビルドとコンテナー レジストリーへの push をした後、この Action で新しいプレビュー用リビジョンを作り、作ったプレビュー用リビジョンの専用 URL を使って、実際の動作を確認する。

Pull Request を閉じた時のワークフローとして、作ったプレビュー用リビジョンを非アクティブにすることもできる。

プレビュー用リビジョンのコンテナーをどうやって本番用リビジョンとするかはお任せ。
リビジョンの動作を確認した後に Traffic を 100 に変えてもいいし、リリース用のブランチへのマージの際に (プレビュー用のリビジョンを非アクティブにした後に) 別のワークフローで改めて Traffic が 100 の本番用リビジョンをリリースしてもいい。

ワークフロー サンプル

この Action を使ったサンプルのワークフローはこちら。

github.com

以下は動作概要。

PR を Open した時

  1. コンテナー イメージをビルド
  2. ビルドしたコンテナー イメージを Azure Container Registry へ docker push
  3. この Action で Azure Container Apps へプレビュー用リビジョンを作成
  4. プレビュー用 URL を PR にコメント

PR を Close/Merge した時

  1. この Action で Azure Container Apps へプレビュー用リビジョンを非アクティブ
  2. PR へのコメントからプレビュー用 URL を削除

検討しないといけないこと

まだリリースほやほやなので、いくつか残課題も。

  • コンテナー イメージ名以外のパラメータ (env, cmd, etc)
  • 複数コンテナー対応
     :
    etc.

オープンソースなので、ご意見いただきながら改善していければ。

あと現在 45 stars★ (2022/10/31 現在) 。

こちらもまだまだ絶賛募集中。

余談

あとハッカソン イベントの参加賞 (自己申告制) として T シャツ👕貰った。

余談でもすらない戯言

このブログへのアクセスが 10/28 だけスパイクしてた。

まぁ、あの記事へのアクセスだろう。
また Shokz のビープ音で検索している人が増えたか。

*1:ただ実際に自分がやったことは、Dev Container 作ったり、バグの再現/検証のお手伝いだったりで、メインのコードはあまり書いてない。

*2:最近ドメイン名が docs.microsoft.com から learn.microsoft.com に変わったみたい