Azure App Service のカスタム コンテナーを構成する

このガイドでは、App Service の Windows アプリのコンテナー化の主要概念および手順について説明します。 Azure App Service の新しいユーザーは、最初にカスタム コンテナー クイック スタートとチュートリアルに従ってください。

このガイドでは、App Service の Linux アプリのコンテナー化の主要概念および手順について説明します。 Azure App Service を初めて使用する場合は、最初にカスタム コンテナー クイック スタートとチュートリアルに従ってください。 サイドカー コンテナー (プレビュー) については、「チュートリアル: Azure App Service でカスタム コンテナーのサイドカー コンテナーを構成する (プレビュー)」を参照してください。

サポートされている親イメージ

カスタム Windows イメージの場合は、必要なフレームワークに合った適切な親イメージ (ベース イメージ)を選択する必要があります。

• .NET Framework のアプリをデプロイするには、Windows Server 2019 Core 長期サービス チャネル (LTSC) リリースに基づく親イメージを使用します。
• .NET Core のアプリをデプロイするには、Windows Server 2019 Nano 半期サービス チャネル (SAC) リリースに基づく親イメージを使用します。

アプリの起動中は、親イメージのダウンロードに多少の時間がかかります。 ただし、Azure App Service にあらかじめキャッシュされている次のいずれかの親イメージを使用することで、起動時間を短縮することができます。

• mcr.microsoft.com/windows/servercore:ltsc2022
• mcr.microsoft.com/windows/servercore:ltsc2019
• mcr.microsoft.com/dotnet/framework/aspnet:4.8-windowsservercore-ltsc2022
• mcr.microsoft.com/dotnet/framework/aspnet:4.8-windowsservercore-ltsc2019
• mcr.microsoft.com/dotnet/runtime:6.0-nanoserver-ltsc2022
• mcr.microsoft.com/dotnet/runtime:6.0-nanoserver-1809
• mcr.microsoft.com/dotnet/aspnet:6.0-nanoserver-ltsc2022
• mcr.microsoft.com/dotnet/aspnet:6.0-nanoserver-1809

IIS または .NET Framework (4.0 以降) ベースのコンテナーの場合、これらは、App Service によって .NET アプリ設定と接続文字列として System.ConfigurationManager に挿入されます。 他のすべての言語またはフレームワークでは、これらは、次のいずれかの対応するプレフィックス付きの環境変数としてプロセスに提供されます。

• APPSETTING_
• SQLCONTR_
• MYSQLCONTR_
• SQLAZURECOSTR_
• POSTGRESQLCONTR_
• CUSTOMCONNSTR_

この方法は単一のコンテナー アプリまたは複数のコンテナー アプリの両方で利用できます。ただし、環境変数は docker compose.yml ファイルで指定されます。

カスタム コンテナー ファイル システムの C:\home ディレクトリを使用することで、再起動間でファイルを保持することや、インスタンス間でそれらのファイルを共有することができます。 カスタム コンテナーが永続的ストレージにアクセスできるようにするために、C:\home ディレクトリが用意されています。

永続的ストレージが無効になると、C:\home ディレクトリへの書き込みは、アプリの再起動後、または複数のインスタンス間で保持されません。 永続的ストレージが有効になると、C:\home ディレクトリへのすべての書き込みは存続し、スケールアウトされたアプリのすべてのインスタンスからアクセスできます。 また、コンテナーの起動時に、コンテナーの C:\home ディレクトリー内のコンテンツが、永続的ストレージに既に存在する既存のファイルによって上書きされます。

唯一の例外は C:\home\LogFiles ディレクトリです。このディレクトリは、コンテナーとアプリケーションのログを保存するために使用されます。 永続的ストレージが有効になっているか無効になっているかに関係なく、ファイル システムのオプションでアプリケーションのログ記録が有効になっていれば、アプリが再起動しても、このフォルダーは常に保持されます。 つまり、永続的ストレージを有効または無効にしても、アプリケーションのログ記録の動作には影響しません。

既定では、Windows カスタム コンテナーで永続的ストレージは有効になっています。 これを無効にするには、Cloud Shell を使用して、WEBSITES_ENABLE_APP_SERVICE_STORAGE アプリ設定値を false に設定します。 Bash では次のとおりです。

az webapp config appsettings set --resource-group <group-name> --name <app-name> --settings WEBSITES_ENABLE_APP_SERVICE_STORAGE=false

PowerShell では次のとおりです。

Set-AzWebApp -ResourceGroupName <group-name> -Name <app-name> -AppSettings @{"WEBSITES_ENABLE_APP_SERVICE_STORAGE"=false}

カスタム コンテナー ファイル システムの /home ディレクトリを使用することで、再起動間でファイルを保持することや、インスタンス間でそれらのファイルを共有することができます。 カスタム コンテナーが永続的ストレージにアクセスできるようにするために、/home ディレクトリが用意されています。 /home 内にデータを保存すると、App Service プランに含まれる記憶領域のクォータに影響します。

永続的ストレージが無効になると、/home ディレクトリへの書き込みは、アプリの再起動後、または複数のインスタンス間で保持されません。 永続的ストレージが有効になると、/home ディレクトリへのすべての書き込みは存続し、スケールアウトされたアプリのすべてのインスタンスからアクセスできます。 また、コンテナーの起動時に、コンテナーの /home ディレクトリー内のコンテンツが、永続的ストレージに既に存在する既存のファイルによって上書きされます。

唯一の例外は /home/LogFiles ディレクトリです。このディレクトリは、コンテナーとアプリケーションのログを保存するために使用されます。 永続的ストレージが有効になっているか無効になっているかに関係なく、ファイル システムのオプションでアプリケーションのログ記録が有効になっていれば、アプリが再起動しても、このフォルダーは常に保持されます。 つまり、永続的ストレージを有効または無効にしても、アプリケーションのログ記録の動作には影響しません。

データは /home またはマウント済み Azure ストレージ パスに書き込むことをお勧めします。 これらのパスの外部に書き込まれたデータは、再起動すると保持されず、App Service プランのファイル ストレージ クォータとは別の、プラットフォーム マネージドのホスト ディスク領域に保存されます。

Linux カスタム コンテナーの永続ストレージは、既定では "無効" になっています。 これを有効にするには、Cloud Shell を使用して、WEBSITES_ENABLE_APP_SERVICE_STORAGE アプリ設定値を true に設定します。 Bash では次のとおりです。

az webapp config appsettings set --resource-group <group-name> --name <app-name> --settings WEBSITES_ENABLE_APP_SERVICE_STORAGE=true

PowerShell では次のとおりです。

Set-AzWebApp -ResourceGroupName <group-name> -Name <app-name> -AppSettings @{"WEBSITES_ENABLE_APP_SERVICE_STORAGE"=true}

ASP.NET マシン キーの挿入をカスタマイズする

コンテナーの開始時、自動的に生成されたキーが ASP.NET 暗号ルーチンのマシン キーとしてコンテナーに挿入されます。 コンテナー内のこれらのキーを見つけるには、環境変数 MACHINEKEY_Decryption、MACHINEKEY_DecryptionKey、MACHINEKEY_ValidationKey、MACHINEKEY_Validation を探し ます。

各再起動時の新しいキーによって ASP.NET フォーム認証とビュー状態がリセットされることがあります (それらにアプリが依存している場合)。 キーが自動的に再生成されないようにするには、それらを App Service アプリ設定として手動で設定します。

コンテナーに接続する

診断タスクのために Windows コンテナーに直接接続し、SSH オプションを選択するには、https://<app-name>.scm.azurewebsites.net/ に移動します。 コンテナーとの直接 SSH セッションが確立され、コンテナー内でコマンドを実行できます。

• その上にあるグラフィカル ブラウザー (共有ストレージ内のファイルのみを表示) とは別に機能します。
• スケールアウトされたアプリでは、SSH セッションはコンテナー インスタンスのいずれかに接続されています。 上部の Kudu メニューの [インスタンス] ドロップダウンから別のインスタンスを選択できます。
• SSH セッション内からコンテナーに対して行った変更は、Docker イメージの一部ではないため、アプリの再起動時には存続しません (共有ストレージ内の変更は除きます)。 レジストリ設定やソフトウェアのインストールなどの変更を保持するには、Dockerfile の一部にします。

診断ログにアクセスする

App Service は、Docker ホストによるアクションと、コンテナー内からのアクティビティをログします。 Docker ホストからのログ (プラットフォーム ログ) は既定で送られますが、コンテナー内からのアプリケーション ログや Web サーバー ログは手動で有効にする必要があります。 詳細については、「アプリケーションのログ記録を有効にする」と「Web サーバーのログ記録を有効にする」を参照してください。

Docker ログにアクセスするには、いくつかの方法があります。

• Azure Portal
• Kudu
• Kudu API
• Azure モニター

Azure Portal

Docker ログは、ポータル内のご自分のアプリの [コンテナーの設定] ページに表示されます。 ログは切り詰められますが、[ダウンロード] を選択してすべてのログをダウンロードすることができます。

Kudu から

https://<app-name>.scm.azurewebsites.net/DebugConsole に移動し、LogFiles フォルダーを選択して、個々のログ ファイルを表示します。 LogFiles ディレクトリ全体をダウンロードするには、ディレクトリ名の左側にある[ダウンロード] アイコンを選択します。 このフォルダーには、FTP クライアントを使用してアクセスすることもできます。

永続的な共有ストレージが有効になっていないため、既定では SSH ターミナルで C:\home\LogFiles フォルダーにアクセスすることはできません。 コンソール ターミナルでこの動作を有効にするには、永続的な共有ストレージを有効にします。

FTP クライアントを使用して現在使用中の Docker ログをダウンロードしようとすると、ファイル ロックが原因でエラーが発生することがあります。

Kudu API を使用する

https://<app-name>.scm.azurewebsites.net/api/logs/docker に直接移動して、Docker ログのメタデータを表示します。 複数のログ ファイルが表示される場合があります。また、href プロパティを使用すると、ログ ファイルを直接ダウンロードできます。

すべてのログを 1 つの ZIP ファイルにまとめてダウンロードするには、https://<app-name>.scm.azurewebsites.net/api/logs/docker/zip にアクセスします。

コンテナー メモリをカスタマイズする

既定では、Azure App Service にデプロイされたすべての Windows コンテナーにメモリ制限が構成されています。 次の表は、App Service プラン SKU ごとの既定の設定を示しています。

この値を変更するには、Cloud Shell を使用して WEBSITE_MEMORY_LIMIT_MB アプリ設定を指定します。 Bash では次のとおりです。

az webapp config appsettings set --resource-group <group-name> --name <app-name> --settings WEBSITE_MEMORY_LIMIT_MB=2000

PowerShell では次のとおりです。

Set-AzWebApp -ResourceGroupName <group-name> -Name <app-name> -AppSettings @{"WEBSITE_MEMORY_LIMIT_MB"=2000}

この値は MB 単位で定義されており、ホストの合計物理メモリ以下である必要があります。 たとえば、8 GB の RAM を備えた App Service プランでは、すべてのアプリの累積合計 WEBSITE_MEMORY_LIMIT_MB が 8 GB を超えないようにする必要があります。 各価格レベルで使用できるメモリ量に関する情報については、「App Service の価格」の Premium v3 サービス プランに関するセクションを参照してください。

コンピューティング コアの数をカスタマイズする

既定では、Windows コンテナーは、選択した価格レベルで使用できるすべてのコアで実行されます。 たとえば、ステージング スロットで使用されるコアの数を減らすことができます。 コンテナーによって使用されるコアの数を減らすには、WEBSITE_CPU_CORES_LIMIT アプリ設定を、希望するコア数に設定します。 これは、Cloud Shell を使用して設定できます。 Bash では次のとおりです。

az webapp config appsettings set --resource-group <group-name> --name <app-name> --slot staging --settings WEBSITE_CPU_CORES_LIMIT=1

PowerShell では次のとおりです。

Set-AzWebApp -ResourceGroupName <group-name> -Name <app-name> -AppSettings @{"WEBSITE_CPU_CORES_LIMIT"=1}

ポータルまたは Kudu ポータル (https://<app-name>.scm.azurewebsites.net/webssh/host) から SSH セッションを開き、PowerShell を使用して以下のコマンドを入力して、調整された番号を確認します。 各コマンドは数値を出力します。

Get-ComputerInfo | ft CsNumberOfLogicalProcessors # Total number of enabled logical processors. Disabled processors are excluded.
Get-ComputerInfo | ft CsNumberOfProcessors # Number of physical processors.

プロセッサは、マルチコアまたはハイパースレッディングのプロセッサにすることができます。 各価格レベルで使用できるコア数に関する情報については、「App Service の価格」の Premium v3 サービス プランに関するセクションを参照してください。

正常性 ping の動作をカスタマイズする

App Service では、コンテナーが開始して HTTP ping に応答すると、コンテナーが正常に開始したと見なされます。 正常性 ping 要求には、ヘッダー User-Agent= "App Service Hyper-V Container Availability Check" が含まれています。 コンテナーが起動したが、一定の時間が経過しても ping に応答しない場合、App Service は、コンテナーが起動しなかったことを示すイベントを Docker ログに記録します。

アプリケーションがリソースを大量に消費する場合、コンテナーは時間内に HTTP ping に応答しない可能性があります。 HTTP ping が失敗したときのアクションを制御するには、CONTAINER_AVAILABILITY_CHECK_MODE アプリ設定を指定します。 これは、Cloud Shell を使用して設定できます。 Bash では次のとおりです。

az webapp config appsettings set --resource-group <group-name> --name <app-name> --settings CONTAINER_AVAILABILITY_CHECK_MODE="ReportOnly"

PowerShell では次のとおりです。

Set-AzWebApp -ResourceGroupName <group-name> -Name <app-name> -AppSettings @{"CONTAINER_AVAILABILITY_CHECK_MODE"="ReportOnly"}

指定可能な値を次の表に示します。

グループの管理されたサービス アカウントのサポート

グループの管理されたサービス アカウント (gMSA) は現在、App Service の Windows コンテナーではサポートされていません。

SSH を有効にする

Secure Shell (SSH) は、一般にコマンド ライン ターミナルから管理コマンドをリモートで実行するために使用されます。 カスタム コンテナーを使って Azure portal の SSH コンソール機能を有効にするには、次の手順が必要です。

1. 次の例の内容で標準の sshd_config ファイルを作成し、アプリケーション プロジェクトのルート ディレクトリに配置します。

   Port 			2222
   ListenAddress 		0.0.0.0
   LoginGraceTime 		180
   X11Forwarding 		yes
   Ciphers aes128-cbc,3des-cbc,aes256-cbc,aes128-ctr,aes192-ctr,aes256-ctr
   MACs hmac-sha1,hmac-sha1-96
   StrictModes 		yes
   SyslogFacility 		DAEMON
   PasswordAuthentication 	yes
   PermitEmptyPasswords 	no
   PermitRootLogin 	yes
   Subsystem sftp internal-sftp
   

   Note

   このファイルを使って OpenSSH を構成します。Azure portal の SSH 機能に準拠するために、次の項目を含める必要があります。

   • Port は 2222 に設定されている必要があります。
   • Ciphers には、aes128-cbc,3des-cbc,aes256-cbc の項目を少なくとも 1 つ含める必要があります。
   • MACs には、hmac-sha1,hmac-sha1-96 の項目を少なくとも 1 つ含める必要があります。

2. entrypoint.sh というエントリポイント スクリプトを作成し (または既存のエントリポイント ファイルを変更し)、アプリケーションの起動コマンドと共に、SSH サービスを開始するコマンドを追加します。 次の例では、Python アプリケーションの開始を示しています。 最後のコマンドは、プロジェクトの言語またはスタックに応じて置き換えます。

   • Debian
   • Alpine

   #!/bin/sh
   set -e
   service ssh start
   exec gunicorn -w 4 -b 0.0.0.0:8000 app:app
   

3. ベース イメージ ディストリビューションに応じて、Dockerfile に次の手順を追加します。 これらの手順では、新しいファイルのコピー、OpenSSH サーバーのインストール、適切なアクセス許可の設定、カスタム エントリポイントの構成、アプリケーションと SSH サーバーに必要なポートの公開をそれぞれ行います。

   • Debian
   • Alpine

   COPY entrypoint.sh ./
   
   # Start and enable SSH
   RUN apt-get update \
       && apt-get install -y --no-install-recommends dialog \
       && apt-get install -y --no-install-recommends openssh-server \
       && echo "root:Docker!" | chpasswd \
       && chmod u+x ./entrypoint.sh
   COPY sshd_config /etc/ssh/
   
   EXPOSE 8000 2222
   
   ENTRYPOINT [ "./entrypoint.sh" ] 
   

   Note

   ルート パスワードは、コンテナーとの SSH セッションにアクセスできるように App Service によって使用されるため、Docker! と正確に同じである必要があります。 この構成は、コンテナーへの外部接続を許可しません。 コンテナーのポート 2222 は、プライベート仮想ネットワークのブリッジ ネットワーク内でのみアクセスでき、インターネット上の攻撃者からはアクセスできません。

4. Docker イメージをリビルドしてレジストリにプッシュしてから、Azure portal で Web App SSH 機能をテストします。

追加のトラブルシューティングの情報については、Azure App Service のブログ「Enabling SSH on Linux Web App for Containers」(コンテナー用 Linux Web アプリで SSH を有効にする) を参照してください。

診断ログにアクセスする

コンテナー内から生成されたコンソール ログにアクセスできます。

まず、次のコマンドを実行して、コンテナーのログ記録をオンにします。

az webapp log config --name <app-name> --resource-group <resource-group-name> --docker-container-logging filesystem

<app-name> と <resource-group-name> は、Web アプリに適した名前に置き換えます。

コンテナーのログ記録がオンになったら、次のコマンドを実行して、ログのストリームを確認します。

az webapp log tail --name <app-name> --resource-group <resource-group-name>

コンソール ログがすぐに表示されない場合は、30 秒以内にもう一度確認します。

任意のタイミングでログのストリーミングを停止するには、Ctrl+C キーを押します。

ブラウザーから https://<app-name>.scm.azurewebsites.net/api/logs/docker でログ ファイルを検査することもできます。

複数コンテナー アプリを構成する

• Docker Compose で永続的ストレージを使用する
• プレビューの制限事項
• Docker Compose のオプション

Docker Compose で永続的なストレージを使用する

WordPress のような複数コンテナー アプリでは、永続的ストレージが適切に機能する必要があります。 有効にするには、Docker Compose 構成が、コンテナー外の保存場所を指す必要があります。 コンテナー内部の保存場所では、アプリの再起動後に変更内容が保持されません。

Cloud Shell で az webapp config appsettings set コマンドを使用して、WEBSITES_ENABLE_APP_SERVICE_STORAGE アプリ設定を指定することで、永続的ストレージを有効にします。

az webapp config appsettings set --resource-group <group-name> --name <app-name> --settings WEBSITES_ENABLE_APP_SERVICE_STORAGE=TRUE

docker-compose.yml ファイルで、volumes オプションを ${WEBAPP_STORAGE_HOME} にマップします。

WEBAPP_STORAGE_HOME は、アプリの永続的なストレージにマップされる App Service の環境変数です。 次に例を示します。

wordpress:
  image: <image name:tag>
  volumes:
  - "${WEBAPP_STORAGE_HOME}/site/wwwroot:/var/www/html"
  - "${WEBAPP_STORAGE_HOME}/phpmyadmin:/var/www/phpmyadmin"
  - "${WEBAPP_STORAGE_HOME}/LogFiles:/var/log"

プレビューの制限事項

複数コンテナーは現在プレビュー段階です。 次の App Service プラットフォーム機能はサポートされません。

• 認証/認可
• マネージド ID
• CORS
• 仮想ネットワーク統合は Docker Compose シナリオではサポートされません
• 現在、Azure App Service の Docker Compose には 4,000 文字の制限があります。

Docker Compose のオプション

以下の一覧は、Docker Compose 構成オプションでサポートされているものとサポートされていないものを示しています。

サポートされているオプション

• command
• entrypoint
• environment
• image
• ports
• restart
• services
• volumes (Azure Storage へのマッピングはサポートされていません)

サポートされていないオプション

• build (禁止)
• depends_on (無視)
• networks (無視)
• secrets (無視)
• ports (80 および 8080 以外) (無視)
• docker とは異なる、$variable and ${variable} のような既定の環境変数

構文の制限事項

• 常に "version x.x" がファイル内の最初の YAML ステートメントである必要があります
• ポート セクションでは、引用符で囲んだ数値を使用する必要があります
• イメージおよびボリューム セクションは引用符で囲む必要があり、アクセス許可の定義を含めることはできません
• ボリューム セクションで、ボリューム名の後に空の中かっこを含めないでください

ログの robots933456

コンテナー ログで次のメッセージが表示されることがあります。

2019-04-08T14:07:56.641002476Z "-" - - [08/Apr/2019:14:07:56 +0000] "GET /robots933456.txt HTTP/1.1" 404 415 "-" "-"

このメッセージは無視してかまいません。 /robots933456.txt は、コンテナーが要求を処理できるかどうかを調べるために App Service が使用するダミーの URL パスです。 404 応答は、パスが存在しないことを示すだけですが、コンテナーが正常であり、要求に応答できる状態であることを App Service に知らせます。