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

この記事では、Azure App Service で実行されるようにカスタム コンテナーを構成する方法を示します。

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

このガイドでは、App Service の Linux アプリのコンテナー化の主要概念および手順について説明します。 Azure App Service を使用したことがない場合は、最初にカスタム コンテナー クイック スタートチュートリアルに従ってください。 複数コンテナー アプリのクイック スタートチュートリアルもあります。

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

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

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

カスタム コンテナーの Docker イメージを変更する

既存のカスタム コンテナーの現在の Docker イメージを新しいイメージに変更するには、次のコマンドを使用します。

az webapp config container set --name <app-name> --resource-group <group-name> --docker-custom-image-name <docker-hub-repo>/<image>

プライベート レジストリからイメージを使用する

Azure Container Registry などのプライベート レジストリから イメージを使用するには、次のコマンドを実行します。

az webapp config container set --name <app-name> --resource-group <group-name> --docker-custom-image-name <image-name> --docker-registry-server-url <private-repo-url> --docker-registry-server-user <username> --docker-registry-server-password <password>

<username> および <password> には、プライベート レジストリ アカウントのログイン資格情報を指定します。

マネージド ID を使用して Azure Container Registry からイメージをプルする

次の手順を実行し、マネージド ID を使用して ACR からプルするための Web アプリを構成します。 この手順では、システム割り当てマネージド ID を使用しますが、ユーザー割り当てマネージド ID も使用できます。

  1. az webapp identity assign コマンドを使用して、Web アプリのシステム割り当てマネージド ID を有効にします。

    az webapp identity assign --resource-group <group-name> --name <app-name> --query principalId --output tsv
    

    <app-name> は、前のステップで使用した名前に置き換えてください。 コマンドからは、--クエリ引数と --出力引数のフィルターを通じて、割り当てられた ID のサービス プリンシパル ID が出力されます。このサービス プリンシパルは、この後すぐに使用します。

  2. Azure Container Registry のリソース ID を取得します。

    az acr show --resource-group <group-name> --name <registry-name> --query id --output tsv
    

    <registry-name> をレジストリの名前に置き換えます。 コマンドからは、--クエリ引数と --出力引数のフィルターを通じて、Azure Container Registry のリソース ID が出力されます。

  3. コンテナー レジストリへのアクセス許可をマネージド ID に与えます。

    az role assignment create --assignee <principal-id> --scope <registry-resource-id> --role "AcrPull"
    

    次の値を置き換えます。

    • <principal-id> を、az webapp identity assign コマンドで得たサービス プリンシパル ID に置き換えます。
    • <registry-resource-id>az acr show コマンドで得たコンテナー レジストリの ID に置き換えます

    これらのアクセス許可の詳細については、「Azure ロールベースのアクセス制御とは」を参照してください。

  4. マネージ ID を使用して Azure Container Registry からプルするようにアプリを構成します。

    az webapp config set --resource-group <group-name> --name <app-name> --generic-configurations '{"acrUseManagedIdentityCreds": true}'
    

    次の値を置き換えます。

    • <app-name>: Web アプリの名前。

    ヒント

    PowerShell コンソールを使用してコマンドを実行する場合は、この手順と次の手順で --generic-configurations 引数の文字列をエスケープする必要があります。 例: --generic-configurations '{\"acrUseManagedIdentityCreds\": true'

  5. (省略可能) アプリでユーザー割り当てマネージド ID を使用する場合は、これが Web アプリ上で構成されていることを確認してから、追加の acrUserManagedIdentityID プロパティを設定し、クライアント ID を指定します。

    az identity show --resource-group <group-name> --name <identity-name> --query clientId --output tsv
    

    ユーザー割り当てマネージド ID の <identity-name> を置き換え、出力 <client-id> を使用して、ユーザー割り当てマネージドを構成します。

    az  webapp config set --resource-group <group-name> --name <app-name> --generic-configurations '{"acrUserManagedIdentityID": "<client-id>"}'
    

これで設定がすべて完了しました。Web アプリでは、Azure Container Registry からプルするために、マネージド ID が使用されます。

ネットワークで保護されたレジストリからイメージを使用する

仮想ネットワークまたはオンプレミス内のレジストリに接続してプルするには、VNet 統合機能を使用して、アプリを仮想ネットワークに接続する必要があります。 これは、プライベート エンドポイントを使用する Azure Container Registry の場合にも必要です。 ネットワークと DNS 解決が構成されている場合は、アプリ設定 WEBSITE_PULL_IMAGE_OVER_VNET=true を設定して、VNet を介したイメージ プルのルーティングを有効にします。

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

更新されたコンテナーが表示されない

新しいコンテナーを指すように Docker コンテナー設定を変更した場合、アプリが新しいコンテナーからの HTTP 要求を処理するまでに数分かかることがあります。 新しいコンテナーがプルされ、開始されている間、App Service は古いコンテナーからの要求を引き続き処理します。 新しいコンテナーが開始され、要求を受信する準備が整った場合にのみ、App Service がそれに対する要求の送信を開始します。

コンテナー イメージの格納方法

App Service でカスタム Docker イメージを初めて実行する場合、App Service は docker pull を行い、すべてのイメージ レイヤーをプルします。 これらのレイヤーは、オンプレミスの Docker を使用しているかのようにディスクに格納されます。 アプリが再起動するたびに、App Service は docker pull を実行しますが、変更されたレイヤーのみをプルします。 変更がなかった場合、App Service はローカル ディスク上の既存のレイヤーを使用します。

価格レベルのスケールアップやスケールダウンなど、何らかの理由でアプリがコンピューティング インスタンスを変更した場合、App Service はすべてのレイヤーを再度プルする必要があります。 さらにインスタンスを追加するためにスケールアウトする場合も同様です。 また、スケーリング操作を行わなくてもアプリ インスタンスが変更されることがまれにあります。

ポート番号を構成する

既定では、App Service はカスタム コンテナーがポート 80 またはポート 8080 のどちらかでリッスンしていることを前提としています。 コンテナーが別のポートをリッスンしている場合は、App Service アプリで WEBSITES_PORT アプリ設定を指定します。 これは、Cloud Shell を使用して設定できます。 Bash では次のとおりです。

az webapp config appsettings set --resource-group <group-name> --name <app-name> --settings WEBSITES_PORT=8000

PowerShell では次のとおりです。

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

現在、App Service では、コンテナーが HTTP 要求に対して 1 つのポートのみを公開することが許可されています。

環境変数を構成する

カスタム コンテナーには、外部で指定する必要がある環境変数を使用できます。 これらは、Cloud Shell 経由で渡すことができます。 Bash では次のとおりです。

az webapp config appsettings set --resource-group <group-name> --name <app-name> --settings DB_HOST="myownserver.mysql.database.azure.com"

PowerShell では次のとおりです。

Set-AzWebApp -ResourceGroupName <group-name> -Name <app-name> -AppSettings @{"DB_HOST"="myownserver.mysql.database.azure.com"}

アプリを実行すると、App Service アプリ設定が環境変数としてプロセスに自動的に挿入されます。 コンテナー環境変数は、URL https://<app-name>.scm.azurewebsites.net/Env を使用して確認できます。

プライベート レジストリまたは Docker Hub からのイメージがアプリで使用される場合、リポジトリにアクセスするための資格情報は、環境変数 DOCKER_REGISTRY_SERVER_URLDOCKER_REGISTRY_SERVER_USERNAME、および DOCKER_REGISTRY_SERVER_PASSWORD に保存されます。 セキュリティ上のリスクがあるため、これらの予約済み変数名はアプリケーションに対して公開されません。

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 アプリ設定値を 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}

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

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

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

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

既定では、永続ストレージは Linux カスタム コンテナーで有効になっています。 これを無効にするには、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}

Note

独自の永続的ストレージを構成することもできます。

HTTPS セッションの検出

App Service は、フロントエンドで TLS/SSL を終了します。 つまり、TLS/SSL 要求がアプリに到達することはありません。 アプリに TLS/SSL のサポートを実装する必要はないため、実装すべきではありません。

フロントエンドは Azure データ センター内に配置されます。 アプリで TLS/SSL を使用する場合、インターネット経由のトラフィックは常に安全に暗号化されます。

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

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

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

コンテナーに接続する

診断タスクのために Windows コンテナーに直接接続するには、https://<app-name>.scm.azurewebsites.net/DebugConsole に移動します。 しくみは次のとおりです。

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

診断ログにアクセスする

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

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

Azure Portal

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

Kudu コンソールから

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

コンソール ターミナルでは、永続的な共有ストレージが有効になっていないため、既定では 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 コンテナーは、1 GB の RAM に制限されます。 この値を変更するには、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}

Note

アプリ設定を更新すると、自動再起動がトリガーされ、ダウンタイムが最小限に抑えられます。 運用アプリの場合は、それをステージング スロットに入れ替え、ステージング スロットでアプリ設定を変更してから、運用環境に戻すことを検討してください。

Kudu コンソール (https://<app-name>.scm.azurewebsites.net) に移動して、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"}

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

[値] 説明
修復 3 回連続して可用性チェックを実行した後にコンテナーを再起動する
ReportOnly 既定値。 コンテナーを再起動しないが、3 回連続して可用性チェックを実行した後、そのコンテナーについて Docker ログに報告します。
"オフ" 可用性を確認しません。

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

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

SSH を有効にする

SSH では、コンテナーとクライアント間の通信をセキュリティで保護できます。 カスタム コンテナーで SSH をサポートするために、Docker イメージ自体に追加する必要があります。

ヒント

App Service 内のすべての組み込み Linux コンテナーは、そのイメージ リポジトリ内に SSH 命令を追加しました。 Node.js 10.14 リポジトリで次のとおり実行し、それをそこで有効にする方法を表示できます。 Node.js 組み込みイメージでの構成は少し異なりますが、原則は同じです。

  • 次の例のように、 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 を構成するものです。ファイル内には、次の項目を含める必要があります。

    • Port は 2222 に設定されている必要があります。
    • Ciphers には、aes128-cbc,3des-cbc,aes256-cbc の項目を少なくとも 1 つ含める必要があります。
    • MACs には、hmac-sha1,hmac-sha1-96 の項目を少なくとも 1 つ含める必要があります。
  • ssh-keygen を使用して SSH キーを作成するための ssh_setup スクリプト ファイルをリポジトリに追加します。

    #!/bin/sh
    
    ssh-keygen -A
    
    #prepare run dir
    if [ ! -d "/var/run/sshd" ]; then
        mkdir -p /var/run/sshd
    fi
    
  • Dockerfile で、次のコマンドを追加します。

    # Install OpenSSH and set the password for root to "Docker!". In this example, "apk add" is the install instruction for an Alpine Linux-based image.
    RUN apk add openssh \
         && echo "root:Docker!" | chpasswd 
    
    # Copy the sshd_config file to the /etc/ssh/ directory
    COPY sshd_config /etc/ssh/
    
    # Copy and configure the ssh_setup file
    RUN mkdir -p /tmp
    COPY ssh_setup.sh /tmp
    RUN chmod +x /tmp/ssh_setup.sh \
        && (sleep 1;/tmp/ssh_setup.sh 2>&1 > /dev/null)
    
    # Open port 2222 for SSH access
    EXPOSE 80 2222
    

    Note

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

  • コンテナーのスタートアップ スクリプトで、SSH サーバーを起動します。

    /usr/sbin/sshd
    

診断ログにアクセスする

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

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

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 で永続的なストレージを使用する

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

Cloud Shellaz 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
  • VNET 統合は、Docker Compose シナリオではサポートされていません。
  • 現在、Azure App Service の Docker Compose には 4,000 文字の制限があります。

Docker Compose のオプション

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

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

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

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

構文の制限事項

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

Note

パブリック プレビューでは、ここで明示的に示されていないその他のオプションが無視されます。

ログの 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 に知らせます。

次のステップ

または、その他のリソースを参照してください: