次の方法で共有

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

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

App Service での Windows アプリのコンテナー化の主な概念と手順について説明します。 新しいユーザーは、最初に カスタム コンテナーのクイックスタート と チュートリアルに従う必要があります。

App Service での Linux アプリのコンテナー化の主な概念と手順について説明します。 新しいユーザーは、最初に カスタム コンテナーのクイックスタート と チュートリアルに従う必要があります。 サイドカー コンテナーについては、「チュートリアル: Azure App Service でカスタム コンテナーのサイドカー コンテナーを構成する」を参照してください。

注

Windows コンテナー イメージプル認証にサービス プリンシパルを使用することはサポートされなくなりました。 Windows コンテナーと Linux コンテナーの両方にマネージド ID を使用することをお勧めします。

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

カスタム Windows イメージに必要なフレームワークの適切な 親イメージ (基本イメージ) を選択します。

  • .NET Framework アプリを展開するには、Windows Server 2019 Core Long-Term サービス チャネル リリースに基づく親イメージを使用します。
  • .NET Core アプリを展開するには、Windows Server 2019 Nano Annual Channel リリースに基づく親イメージを使用します。

アプリの起動時に親イメージをダウンロードするには少し時間がかかります。 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 を使用して Azure Container Registry からプルするように Web アプリを構成するには、次の手順に従います。 この手順ではシステム割り当てマネージド ID を使用しますが、ユーザー割り当てマネージド ID を使用することもできます。

  1. コマンドを使用して、Web アプリのaz webapp identity assign有効にします。

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

    <app-name>を前の手順で使用した名前に置き換えます。 --query引数と--output引数でフィルター処理されたコマンドの出力は、割り当てられた ID のサービス プリンシパル ID です。

  2. コンテナー レジストリのリソース ID を取得します。

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

    <registry-name>をレジストリの名前に置き換えます。 --query引数と--output引数でフィルター処理されたコマンドの出力は、コンテナー レジストリのリソース ID です。

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

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

    次の値を置き換えます。

    • <
    • <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 を使用する場合は、この 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 アプリでは、マネージド ID を使用して Azure Container Registry からプルできるようになりました。

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

仮想ネットワークまたはオンプレミス内のレジストリに接続してプルするには、アプリを仮想ネットワークと統合する必要があります。 また、プライベート エンドポイントを使用した Azure Container Registry の仮想ネットワーク統合も必要です。 ネットワークと DNS 解決を構成したら、仮想ネットワーク経由でイメージ プルのルーティングを有効にします。 vnetImagePullEnabled サイト設定を構成します。

az resource update --resource-group <group-name> --name <app-name> --resource-type "Microsoft.Web/sites" --set properties.vnetImagePullEnabled [true|false]

更新されたコンテナーが表示されない場合のトラブルシューティング

新しいコンテナーを指すように 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 でリッスンすることを前提としています。 コンテナーが別のポートをリッスンしている場合は、App Service アプリで WEBSITES_PORT アプリ設定を指定します。 Azure 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 イメージを使用してコンテナーに SSH 接続する場合、 env や printenvなどのコマンドを使用しようとすると、いくつかの環境変数のみが表示されることがあります。 実行時に使用するためにアプリケーションに渡すような、コンテナー内のすべての環境変数を表示するには、エントリポイント スクリプトに次の行を追加します。

eval $(printenv | sed -n "s/^\([^=]\+\)=\(.*\)$/export \1=\2/p" | sed 's/"/\\\"/g' | sed '/=/s//="/' | sed 's/$/"/' >> /etc/profile)

完全な 例を参照してください。

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

インターネット インフォメーション サービス (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 ディレクトリを使用して、再起動の間にファイルを保持し、インスタンス間で共有することができます。 C:\home ディレクトリを使用すると、カスタム コンテナーは永続ストレージにアクセスできます。 /home内で保存したデータは、App Service プランに含まれるストレージ領域のクォータに影響します。

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

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

/homeまたはマウントされた Azure ストレージ パスにデータを書き込むことをお勧めします。 これらのパスの外部で書き込むデータは、再起動中は永続的ではありません。 データは、App Service プランのファイル ストレージ クォータとは別に、プラットフォームで管理されるホスト ディスク領域に保存されます。

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}

注

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

HTTPS セッションの検出

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

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

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 portal

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

App Service プラン SKU アプリあたりの既定のメモリ制限 (MB 単位)
P1v3 1024
P1Mv3 1024
P2v3 1536
P2Mv3 1536
P3v3 2048
P3Mv3 2048
P4Mv3 2560
P5Mv3 3072

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

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

値 Description
Repair 3 つの連続する可用性チェックの後、コンテナーを再起動します。
ReportOnly 既定値。 3 つの連続する可用性チェックの後、Docker ログにコンテナーを報告しますが、再起動しないでください。
Off 可用性を確認しません。

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

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 アプリで 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 キーを使用します。

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

注

Docker Compose 機能は、2027 年 3 月 31 日に廃止されます。 サイドカー コンテナーは、App Service のマルチコンテナー アプリの後継です。 新しいサービスについては、「 チュートリアル: Azure App Service でカスタム コンテナー用にサイドカー コンテナーを構成する」を参照してください。 App Service の既存のマルチコンテナー アプリについては、「 Docker Compose アプリケーションをサイドカー機能に移行する」を参照してください。

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

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

永続的ストレージを有効にするには、 WEBSITES_ENABLE_APP_SERVICE_STORAGE アプリの設定を設定します。 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 構成オプションとサポートされていない Docker Compose 構成オプションを示します。

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

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

  • build (許可されていません)
  • depends_on (無視)
  • networks (無視)
  • secrets (無視)
  • 80および8080以外のポート (無視)
  • $variableや${variable}などの既定の環境変数 (Docker とは異なります)

構文の制限事項

  • ファイル内の最初の YAML ステートメントは常に version x.xする必要があります。
  • ports セクションでは、引用符で囲まれた数値を使用する必要があります。
  • image > volumeセクションは引用符で囲む必要があり、アクセス許可の定義を持つことはありません。
  • ボリュームセクションには、ボリューム名の後に空の波括弧を含めることはできません。

注

明示的に言及されていないその他のオプションは、プレビューでは無視されます。

ログ内の robots933456 メッセージを無視する

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

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

このメッセージは無視してかまいません。 /robots933456.txt はダミーの URL パスです。 App Service はそれを使用して、コンテナーが要求を提供できるかどうかを確認します。 "404" エラー応答は、パスが存在しないことを示し、コンテナーが正常であり、要求に応答する準備ができていることを App Service に通知します。

関連コンテンツ

  • Last updated on