Azure Container Apps カスタム コンテナー セッション (プレビュー)

Azure Container Apps 動的セッションで提供される組み込みのコード インタープリターに加えて、カスタム コンテナーを使って独自のセッション サンドボックスを定義することもできます。

Note

Azure Container Apps の動的セッションは現在プレビューの段階です。 詳細については、「プレビューの制限事項」を参照してください。

カスタム コンテナー セッションの使い方

カスタム コンテナーを使うと、ニーズに合わせて調整したソリューションを構築できます。 高速な一時的環境でコードを実行、またはアプリケーションを実行し、Hyper-V を使用して安全なサンドボックス空間を提供できます。 さらに、ネットワークの分離を使って構成するオプションもあります。 次に例をいくつか示します。

  • コード インタープリター: 組み込みのインタープリターでサポートされていない言語によって、信頼できないコードをセキュリティで保護されたサンドボックスで実行する必要がある場合、またはコード インタープリター環境を完全に制御する必要がある場合。

  • 分離された実行: 悪意のあるマルチテナント シナリオでアプリケーションを実行する必要がある場合。テナントやユーザーがそれぞれ独自のサンドボックス環境を持ちます。 これらの環境は、互いの環境から、またホスト アプリケーションから分離されます。 例としては、ユーザーが指定したコードを実行するアプリケーション、クラウドベースのシェルへのアクセスをエンド ユーザーに許可するコード、AI エージェント、開発環境などがあります。

カスタム コンテナー セッションを使う

カスタム コンテナー セッションを使うには、まず、カスタム コンテナー イメージを含むセッション プールを作成します。 Azure Container Apps により、指定したイメージを使って、コンテナーが独自の Hyper-V サンドボックスで自動的に起動されます。 コンテナーが起動したら、セッション プールで使用できるようになります。

アプリケーションがセッションを要求すると、プールからすぐにインスタンスが割り当てられます。 セッションは、アイドル状態になるまでアクティブであり続けます。その後、自動的に停止され、破棄されます。

カスタム コンテナー セッション プールの作成

カスタム コンテナー セッション プールを作成するには、コンテナー イメージとプールの構成設定を指定する必要があります。

各セッションの呼び出しやそれとの通信は、HTTP 要求を使用して行います。 これらの要求に応答するために、カスタム コンテナーでは指定したポートで HTTP サーバーを公開する必要があります。

Azure CLI を使ってカスタム コンテナー セッション プールを作成するには、次のコマンドを使って、最新バージョンの Azure CLI と Azure Container Apps 拡張機能を用意します。

az upgrade
az extension add --name containerapp --upgrade --allow-preview true -y

カスタム コンテナー セッション プールには、ワークロード プロファイルが有効な Azure Container Apps 環境が必要です。 環境がない場合は、az containerapp env create -n <ENVIRONMENT_NAME> -g <RESOURCE_GROUP> --location <LOCATION> --enable-workload-profiles コマンドを使って作成します。

az containerapp sessionpool create コマンドを使って、カスタム コンテナー セッション プールを作成します。

次の例では、カスタム コンテナー イメージ myregistry.azurecr.io/my-container-image:1.0 を使って、my-session-pool という名前のセッション プールを作成します。

要求を送信する前に、<> 角かっこの間のプレースホルダーを、セッション プールとセッション識別子の適切な値に置き換えます。

az containerapp sessionpool create \
    --name my-session-pool \
    --resource-group <RESOURCE_GROUP> \
    --environment <ENVIRONMENT> \
    --registry-server myregistry.azurecr.io \
    --registry-username <USER_NAME> \
    --registry-password <PASSWORD> \
    --container-type CustomContainer \
    --image myregistry.azurecr.io/my-container-image:1.0 \ 
    --cpu 1.0 --memory 2.0Gi \
    --target-port 80 \
    --cooldown-period 300 \
    --network-status EgressDisabled \
    --max-sessions 10 \
    --ready-sessions 5 \
    --env-vars "key1=value1" "key2=value2"

このコマンドを実行すると、次の設定でセッション プールが作成されます。

パラメーター 価値 説明
--name my-session-pool セッション プールの名前。
--resource-group my-resource-group セッション プールが含まれるリソース グループ。
--environment my-environment コンテナー アプリの環境の名前またはリソース ID。
--container-type CustomContainer セッション プールのコンテナーの種類。 カスタム コンテナー セッションの場合、CustomContainer にする必要があります。
--image myregistry.azurecr.io/my-container-image:1.0 セッション プール用に使用するコンテナー イメージ。
--registry-server myregistry.azurecr.io コンテナー レジストリ サーバーのホスト名。
--registry-username my-username コンテナー レジストリにログインするユーザー名。
--registry-password my-password コンテナー レジストリにログインするパスワード。
--cpu 1.0 必要な CPU (コア単位)。
--memory 2.0Gi 必要なメモリ。
--target-port 80 イングレス トラフィック用に使うセッション ポート。
--cooldown-period 300 セッションが終了するアイドル状態の秒数。 アイドル期間は、セッションの API が呼び出されるたびにリセットされます。 値は 300 から 3600 までの間にする必要があります。
--network-status 送信ネットワーク トラフィックをセッションから許可するかどうかを指定します。 有効な値は、EgressDisabled (既定値) および EgressEnabled です。
--max-sessions 10 同時に割り当てることができるセッションの最大数。
--ready-sessions 5 セッション プールで常に準備ができている状態にするセッションの目標数。 プールが補充されるよりも速くセッションが割り当てられている場合は、この数を増やします。
--env-vars "key1=value1" "key2=value2" コンテナー内で設定する環境変数。

セッション プールを更新するには、az containerapp sessionpool update コマンドを使用します。

重要

セッションを使って信頼できないコードを実行する場合は、その信頼できないコードからアクセスさせたくない情報やデータを含めないでください。 コードには悪意があり、環境変数、シークレット、ファイルなど、コンテナーに対する完全なアクセス権があるものと想定してください。

セッションでの作業

アプリケーションは、セッション プールの管理 API を使ってセッションと対話します。

カスタム コンテナー セッションのプール管理エンドポイントは、次の形式に従います: https://<SESSION_POOL>.<ENVIRONMENT_ID>.<REGION>.azurecontainerapps.io

セッション プールの管理エンドポイントを取得するには、az containerapp sessionpool show コマンドを使います。

az containerapp sessionpool show \
    --name <SESSION_POOL_NAME> \
    --resource-group <RESOURCE_GROUP> \
    --query "properties.poolManagementEndpoint" \
    --output tsv

プール管理エンドポイントに対するすべての要求には、ベアラー トークンを含む Authorization ヘッダーを含める必要があります。 プール管理 API で認証する方法については、「認証」を参照してください。

各 API 要求には、セッション ID と共にクエリ文字列パラメーター identifier も含める必要があります。 この一意のセッション ID を使用すると、アプリケーションで特定のセッションと対話できます。 セッション識別子について詳しくは、「セッション識別子」を参照してください。

重要

セッション識別子は、その値を作成して管理する際に安全なプロセスを必要とする機密情報です。 この値を保護するために、アプリケーションでは各ユーザーまたはテナントがアクセスできるのはそれ自身のセッションだけであることを確認する必要があります。 セッションへのアクセスをセキュリティで保護しないと、ユーザーのセッション内に保存されているデータの誤用または未承認のアクセスが発生する可能性があります。 詳細については、「セッション識別子」を参照してください

セッションのコンテナーへの要求の転送:

ベース プール管理エンドポイントの後のパス内の内容はすべて、セッションのコンテナーに転送されます。

たとえば、<POOL_MANAGEMENT_ENDPOINT>/api/uploadfile の呼び出しを行うと、要求は 0.0.0.0:<TARGET_PORT>/api/uploadfile にあるセッションのコンテナーにルーティングされます。

継続的なセッションとの対話:

同じセッションに対して継続的に要求を行うことができます。 クールダウン期間が過ぎてもセッションに対する要求が行われない場合、セッションは自動的に削除されます。

要求のサンプル

次の例は、ユーザー ID によるカスタム コンテナー セッションへの要求を示しています。

要求を送信する前に、<> 角かっこの間のプレースホルダーを、要求に固有の値に置き換えます。

POST https://<SESSION_POOL_NAME>.<ENVIRONMENT_ID>.<REGION>.azurecontainerapps.io/<API_PATH_EXPOSED_BY_CONTAINER>?identifier=<USER_ID>
Authorization: Bearer <TOKEN>
{
  "command": "echo 'Hello, world!'"
}

この要求は、そのユーザー ID の識別子を持つカスタム コンテナー セッションに転送されます。 セッションがまだ実行されていない場合、Azure Container Apps は要求を転送する前にプールからセッションを割り当てます。

この例では、セッションのコンテナーは http://0.0.0.0:<INGRESS_PORT>/<API_PATH_EXPOSED_BY_CONTAINER> で要求を受け取ります。

次のステップ