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 Annual Channel (AC) リリースに基づく親イメージを使用します。

アプリの起動時に親イメージをダウンロードするには少し時間がかかります。 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 以降) ベースのコンテナーの場合、資格情報は.NET アプリ設定として System.ConfigurationManager に挿入され、接続文字列は App Service によって自動的に挿入されます。 他のすべての言語またはフレームワークの場合、これらはプロセスの環境変数として提供され、次のいずれかのプレフィックスが付いています。

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

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

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

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

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

既定では、Windows カスタム コンテナーで永続的ストレージは有効になっています。 これを無効にするには、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 Plans ファイル ストレージ クォータとは別に、プラットフォームで管理されるホスト ディスク領域に保存されます。

Linux カスタム コンテナーの永続ストレージは、既定では "無効" になっています。 これを有効にするには、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 コンテナーに直接接続するには、 https://<app-name>.scm.azurewebsites.net/ に移動し、SSH オプションを選択します。 このオプションでは、コンテナー内でコマンドを実行できる直接 SSH セッションが確立されます。

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

診断ログにアクセスする

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

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

• Azure ポータル
• クドゥ
• Kudu API
• Azure モニター

Azure ポータル内で

Docker ログは、Azure portal のアプリの [コンテナーの設定] ページに表示されます。 ログは切り捨てられます。 すべてのログをダウンロードするには、[ ダウンロード] を選択します。

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 ごとの既定の設定を示しています。

この値は、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}

調整された番号を確認するには、Azure portal から SSH セッションを開くか、Kudu ポータル (https://<app-name>.scm.azurewebsites.net/webssh/host) を使用します。 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
   

   注

   このファイルを使って 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 アプリケーションの開始を示しています。 最後のコマンドは、プロジェクトの言語またはスタックに応じて置き換えます。

   • デビアン
   • アルパイン

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

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

   • デビアン
   • アルパイン

   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" ] 
   

   注

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

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

トラブルシューティングの詳細については、Azure App Service のブログ「Linux Web App for Containers での 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+ キーを押します。

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

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

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

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

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

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 構成オプションでサポートされているものとサポートされていないものを示しています。

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

• コマンド
• エントリポイント
• 環境
• 画像
• ポート
• 再起動
• サービス
• 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 に知らせます。