はじめに

に対する回避策 4 となります。
この記事では、カスタムコンテナーを利用する場合の考慮事項について記載します。

カスタムコンテナー利用時のデプロイフローについて

カスタムコンテナーを利用するアプリケーションのデプロイにおいては、zip デプロイ等は必要ないため、Kudu のデプロイメント API を利用することはありません。
基本的にはアプリケーション側が、ACR や DockerHub 等のレジストリから Pull を行うことになるため、アプリケーション側からのアウトバウンド通信となる動作は Private Endpoint や、パブリックネットワークアクセスの制御の対象外となります。

なお、Pull 実行時に VNet を経由させる方法については本記事では言及しません。以下の記事を参考にしてください。
ネットワークで保護されたレジストリからイメージを使用する

ただし、アプリケーションに pull を実行させる契機となる、webhook エンドポイントについては注意が必要となります。

webhook エンドポイントについて

App Service for Container の webhook エンドポイントは [デプロイセンター]ブレードや、az cli で確認することができます。

az webapp deployment container config --name <app-name> --resource-group <group-name> --enable-cd true --query CI_CD_URL --output tsv

実際の値は以下のようなアプリケーションスコープのBasic認証情報込の Kudu のエンドポイントの URL となっています。

https://$<app名>:<認証パスワード>@<app名>.scm.azurewebsites.net/api/registry/webhook

または、

https://$<app名>:<認証パスワード>@<app名>.scm.azurewebsites.net/api/docker/hook

のような値が得られます。

Kudu の Basic 認証については下記の Wiki を参照してください。

これらの API が呼び出されるとアプリケーションは、再起動および指定されているイメージを pull することになりますが、Kudu によって提供されるエンドポイントとなるため、Private Endpoint や、パブリックネットワークアクセスの制御の対象となります。

例えば、ACR からこのエンドポイントに通知を行う場合、パブリックにアクセスできる必要があり、パブリックネットワークアクセスが行なえない状態では Webhook は到達しません。

Webhook のエンドポイントはレジストリからパブリックにアクセスできる必要があります。

回避策

アプリケーションが利用するイメージのタグを latest に固定している場合などは、webhook をきっかけに再起動およびイメージの取得を行う方法は有効ではありますが、同一のタグを更新する運用を行う場合、スケールアウトしているインスタンスによって取得したイメージの内容が異なる可能性がでてきます。
また、イメージのリリースと、アプリケーションが提供するウェブサービスの更新のライフサイクルが同一とも限りません。

そのため、App Service においては、アプリケーションが利用するイメージのタグは明示的にユニークな値として運用することが適していると考えます。

その場合そもそも webhook は必要なく、イメージを随時異なるタグで更新した後に、任意のタイミングでアプリケーションが利用するイメージはアプリケーションの属性として更新することが良いと考えます。

アプリケーションの属性の更新には、Azure Management API が用いられるため、Private Endpoint や、パブリックネットワークアクセスの制御の対象外となります。