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

[アーティクル]
10/25/2023

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

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

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

Note

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

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

カスタム 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

カスタムコンテナーの 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 (ACR) からプルするように Web アプリを構成します。この手順では、システム割り当てマネージド ID を使用しますが、ユーザー割り当てマネージド ID も使用できます。

az webapp identity assign コマンドを使用して、Web アプリのシステム割り当てマネージド ID を有効にします。
```
az webapp identity assign --resource-group <group-name> --name <app-name> --query principalId --output tsv
```
<app-name> は、前のステップで使用した名前に置き換えてください。コマンドからは、--query 引数と --output 引数のフィルターを通じて、割り当てられた ID のサービスプリンシパル ID が出力されます。
Azure Container Registry のリソース ID を取得します。
```
az acr show --resource-group <group-name> --name <registry-name> --query id --output tsv
```
<registry-name> をレジストリの名前に置き換えます。コマンドからは、--query と --output 引数のフィルターを通じて、Azure Container Registry のリソース ID が出力されます。
コンテナーレジストリへのアクセス許可をマネージド 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 ロールベースのアクセス制御とは」を参照してください。
マネージ 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'
(省略可能) アプリでユーザー割り当てマネージド 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 アプリでは、Azure Container Registry からプルするために、マネージド ID が使用されます。

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

仮想ネットワークまたはオンプレミス内のレジストリに接続してプルするには、アプリを仮想ネットワーク (VNET) と統合する必要があります。 VNET 統合は、プライベートエンドポイントを使用する 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 アプリ設定を指定します。これは、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_URL、DOCKER_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 アプリ設定値を 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}

Note

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

HTTPS セッションを検出する

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

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

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

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

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

この値を変更するには、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/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"}

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

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

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

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

SSH を有効にする

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

次の例の内容で標準の 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 つ含める必要があります。
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
```
```
#!/bin/sh
set -e
/usr/sbin/sshd
exec gunicorn -w 4 -b 0.0.0.0:8000 app:app
```
ベースイメージディストリビューションに応じて、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" ] 
```
```
COPY sshd_config /etc/ssh/
COPY entrypoint.sh ./

# Start and enable SSH
RUN apk add openssh \
    && echo "root:Docker!" | chpasswd \
    && chmod +x ./entrypoint.sh \
    && cd /etc/ssh/ \
    && ssh-keygen -A

EXPOSE 8000 2222

ENTRYPOINT [ "./entrypoint.sh" ]
```
Note

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

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

Note

サイドカーコンテナー (プレビュー) は、App Service のマルチコンテナーアプリの後継です。概要については、「チュートリアル: Azure App Service でカスタムコンテナーのサイドカーコンテナーを構成する (プレビュー)」を参照してください。

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 ステートメントである必要があります
ポートセクションでは、引用符で囲んだ数値を使用する必要があります
イメージおよびボリュームセクションは引用符で囲む必要があり、アクセス許可の定義を含めることはできません
ボリュームセクションで、ボリューム名の後に空の中かっこを含めないでください

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

次のステップ

チュートリアル: カスタムコンテナーを使用してカスタムソフトウェアを Azure App Service に移行する

チュートリアル: Azure App Service でカスタムコンテナーのサイドカーコンテナーを構成する (プレビュー)

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

次の方法で共有

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

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

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

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

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

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

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

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

ポート番号を構成する

環境変数を構成する

永続的な共有ストレージを使用する

HTTPS セッションを検出する

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

コンテナーに接続する

診断ログにアクセスする

Azure Portal

Kudu から

Kudu API を使用する

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

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

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

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

SSH を有効にする

診断ログにアクセスする

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

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

プレビューの制限事項

Docker Compose のオプション

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

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

構文の制限事項

ログの robots933456

次のステップ

フィードバック

その他のリソース

次の方法で共有

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

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

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

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

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

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

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

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

ポート番号を構成する

環境変数を構成する

永続的な共有ストレージを使用する

HTTPS セッションを検出する

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

コンテナーに接続する

診断ログにアクセスする

Azure Portal

Kudu から

Kudu API を使用する

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

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

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

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

SSH を有効にする

診断ログにアクセスする

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

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

プレビューの制限事項

Docker Compose のオプション

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

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

構文の制限事項

ログの robots933456

次のステップ

フィードバック

その他のリソース

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

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

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

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

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

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

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

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

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