Azure App Service のカスタム コンテナーを構成するConfigure a custom container for Azure App Service

この記事では、Azure App Service で実行されるようにカスタム コンテナーを構成する方法を示します。This article shows you how to configure a custom container to run on Azure App Service.

このガイドでは、App Service の Windows アプリのコンテナー化の主要概念および手順について説明します。This guide provides key concepts and instructions for containerization of Windows apps in App Service. Azure App Service を使用したことがない場合は、最初にカスタム コンテナー クイック スタートチュートリアルに従ってください。If you've never used Azure App Service, follow the custom container quickstart and tutorial first.

このガイドでは、App Service の Linux アプリのコンテナー化の主要概念および手順について説明します。This guide provides key concepts and instructions for containerization of Linux apps in App Service. Azure App Service を使用したことがない場合は、最初にカスタム コンテナー クイック スタートチュートリアルに従ってください。If you've never used Azure App Service, follow the custom container quickstart and tutorial first. 複数コンテナー アプリのクイック スタートチュートリアルもあります。There's also a multi-container app quickstart and tutorial.

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

カスタム Windows イメージの場合は、必要なフレームワークに合った適切な親イメージ (ベース イメージ)を選択する必要があります。For your custom Windows image, you must choose the right parent image (base image) for the framework you want:

アプリの起動中は、親イメージのダウンロードに多少の時間がかかります。It takes some time to download a parent image during app start-up. ただし、Azure App Service にあらかじめキャッシュされている次のいずれかの親イメージを使用することで、起動時間を短縮することができます。However, you can reduce start-up time by using one of the following parent images that are already cached in Azure App Service:

カスタム コンテナーの Docker イメージを変更するChange the Docker image of a custom container

既存のカスタム コンテナー アプリの現在の Docker イメージを新しいイメージに変更するには、次のコマンドを使用します。To change an existing custom container app from the current Docker image to a new image, use the following command:

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

プライベート レジストリからイメージを使用するUse an image from a private registry

Azure Container Registry などのプライベート レジストリから イメージを使用するには、次のコマンドを実行します。To use an image from a private registry, such as Azure Container Registry, run the following command:

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> には、プライベート レジストリ アカウントのログイン資格情報を指定します。For <username> and <password> , supply the login credentials for your private registry account.

更新されたコンテナーが表示されないI don't see the updated container

新しいコンテナーを指すように Docker コンテナー設定を変更した場合、アプリが新しいコンテナーからの HTTP 要求を処理するまでに数分かかることがあります。If you change your Docker container settings to point to a new container, it may take a few minutes before the app serves HTTP requests from the new container. 新しいコンテナーがプルされ、開始されている間、App Service は古いコンテナーからの要求を引き続き処理します。While the new container is being pulled and started, App Service continues to serve requests from the old container. 新しいコンテナーが開始され、要求を受信する準備が整った場合にのみ、App Service がそれに対する要求の送信を開始します。Only when the new container is started and ready to receive requests does App Service start sending requests to it.

コンテナー イメージの格納方法How container images are stored

App Service でカスタム Docker イメージを初めて実行する場合、App Service は docker pull を行い、すべてのイメージ レイヤーをプルします。The first time you run a custom Docker image in App Service, App Service does a docker pull and pulls all image layers. これらのレイヤーは、オンプレミスの Docker を使用しているかのようにディスクに格納されます。These layers are stored on disk, like if you were using Docker on-premises. アプリが再起動するたびに、App Service は docker pull を実行しますが、変更されたレイヤーのみをプルします。Each time the app restarts, App Service does a docker pull, but only pulls layers that have changed. 変更がなかった場合、App Service はローカル ディスク上の既存のレイヤーを使用します。If there have been no changes, App Service uses existing layers on the local disk.

価格レベルのスケールアップやスケールダウンなど、何らかの理由でアプリがコンピューティング インスタンスを変更した場合、App Service はすべてのレイヤーを再度プルする必要があります。If the app changes compute instances for any reason, such as scaling up and down the pricing tiers, App Service must pull down all layers again. さらにインスタンスを追加するためにスケールアウトする場合も同様です。The same is true if you scale out to add additional instances. また、スケーリング操作を行わなくてもアプリ インスタンスが変更されることがまれにあります。There are also rare cases where the app instances may change without a scale operation.

ポート番号を構成するConfigure port number

既定では、App Service はカスタム コンテナーがポート 80 でリッスンしていることを前提としています。By default, App Service assumes your custom container is listening on port 80. コンテナーが別のポートをリッスンしている場合は、App Service アプリで WEBSITES_PORT アプリ設定を指定します。If your container listens to a different port, set the WEBSITES_PORT app setting in your App Service app. これは、Cloud Shell を使用して設定できます。You can set it via the Cloud Shell. Bash では次のとおりです。In Bash:

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

PowerShell では次のとおりです。In PowerShell:

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

現在、App Service では、コンテナーが HTTP 要求に対して 1 つのポートのみを公開することが許可されています。App Service currently allows your container to expose only one port for HTTP requests.

環境変数を構成するConfigure environment variables

カスタム コンテナーには、外部で指定する必要がある環境変数を使用できます。Your custom container may use environment variables that need to be supplied externally. これらは、Cloud Shell 経由で渡すことができます。You can pass them in via the Cloud Shell. Bash では次のとおりです。In Bash:

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

PowerShell では次のとおりです。In PowerShell:

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

アプリを実行すると、App Service アプリ設定が環境変数としてプロセスに自動的に挿入されます。When your app runs, the App Service app settings are injected into the process as environment variables automatically.

IIS または .NET Framework (4.0 以降) ベースのコンテナーの場合、これらは、App Service によって .NET アプリ設定と接続文字列として System.ConfigurationManager に挿入されます。For IIS or .NET Framework (4.0 or above) based containers, they're injected into System.ConfigurationManager as .NET app settings and connection strings automatically by App Service. 他のすべての言語またはフレームワークでは、これらは、次のいずれかの対応するプレフィックス付きの環境変数としてプロセスに提供されます。For all other language or framework, they're provided as environment variables for the process, with one of the following corresponding prefixes:

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

この方法は単一のコンテナー アプリまたは複数のコンテナー アプリの両方で利用できます。ただし、環境変数は docker compose.yml ファイルで指定されます。This method works both for single-container apps or multi-container apps, where the environment variables are specified in the docker-compose.yml file.

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

アプリのファイル システムの C:\home ディレクトリを使用して、再起動間でファイルを永続化し、インスタンス間でそれらを共有することができます。You can use the C:\home directory in your app's file system to persist files across restarts and share them across instances. アプリの C:\home は、コンテナー アプリが永続的ストレージにアクセスできるようにするために指定されます。The C:\home in your app is provided to enable your container app to access persistent storage.

永続的ストレージが無効になっている場合、C:\home ディレクトリへの書き込みは保持されません。When persistent storage is disabled, writes to the C:\home directory aren't persisted. Docker ホスト ログとコンテナー ログは、コンテナーに接続されていない既定の永続的な共有ストレージに保存されます。Docker host logs and container logs are saved in a default persistent shared storage that is not attached to the container. 永続的ストレージが有効になっている場合、C:\home ディレクトリへのすべての書き込みは保持され、スケールアウトされたアプリのすべてのインスタンスからアクセスでき、C:\home\LogFiles でログにアクセスできます。When persistent storage is enabled, all writes to the C:\home directory are persisted and can be accessed by all instances of a scaled-out app, and log are accessible at C:\home\LogFiles.

既定では、永続的ストレージは " 無効 " になっており、この設定はアプリケーション設定では公開されていません。By default, persistent storage is disabled and the setting is not exposed in the Application Settings. これを有効にするには、Cloud Shell を使用して WEBSITES_ENABLE_APP_SERVICE_STORAGE アプリ設定を指定します。To enable it, set the WEBSITES_ENABLE_APP_SERVICE_STORAGE app setting via the Cloud Shell. Bash では次のとおりです。In Bash:

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

PowerShell では次のとおりです。In PowerShell:

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

アプリのファイル システムの /home ディレクトリを使用して、再起動間でファイルを永続化し、インスタンス間でそれらを共有することができます。You can use the /home directory in your app's file system to persist files across restarts and share them across instances. アプリの /home は、コンテナー アプリが永続的ストレージにアクセスできるようにするために指定されます。The /home in your app is provided to enable your container app to access persistent storage.

永続的ストレージが無効になると、/home ディレクトリへの書き込みは、アプリの再起動後、または複数のインスタンス間で保持されません。When persistent storage is disabled, then writes to the /home directory aren't persisted across app restarts or across multiple instances. 唯一の例外は /home/LogFiles ディレクトリであり、これは Docker およびコンテナーのログを格納するために使用されます。The only exception is the /home/LogFiles directory, which is used to store the Docker and container logs. 永続的ストレージが有効になると、/home ディレクトリへのすべての書き込みは存続し、スケールアウトされたアプリのすべてのインスタンスからアクセスできます。When persistent storage is enabled, all writes to the /home directory are persisted and can be accessed by all instances of a scaled-out app.

既定では、永続的ストレージが 有効 になり、設定はアプリケーション設定では公開されません。By default, persistent storage is enabled and the setting is not exposed in the Application Settings. これを無効にするには、Cloud Shell を使用して WEBSITES_ENABLE_APP_SERVICE_STORAGE アプリ設定を指定します。To disable it, set the WEBSITES_ENABLE_APP_SERVICE_STORAGE app setting via the Cloud Shell. Bash では次のとおりです。In Bash:

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

PowerShell では次のとおりです。In PowerShell:

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

注意

独自の永続的ストレージを構成することもできます。You can also configure your own persistent storage.

HTTPS セッションの検出Detect HTTPS session

App Service は、フロントエンドで TLS/SSL を終了します。App Service terminates TLS/SSL at the front ends. つまり、TLS/SSL 要求がアプリに到達することはありません。That means that TLS/SSL requests never get to your app. アプリに TLS/SSL のサポートを実装する必要はないため、実装すべきではありません。You don't need to, and shouldn't implement any support for TLS/SSL into your app.

フロントエンドは Azure データ センター内に配置されます。The front ends are located inside Azure data centers. アプリで TLS/SSL を使用する場合、インターネット経由のトラフィックは常に安全に暗号化されます。If you use TLS/SSL with your app, your traffic across the Internet will always be safely encrypted.

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

コンテナーの開始時、自動的に生成されたキーが ASP.NET 暗号ルーチンのマシン キーとしてコンテナーに挿入されます。During the container start, automatically generated keys are injected into the container as the machine keys for ASP.NET cryptographic routines. コンテナー内のこれらのキーを見つけるには、環境変数 MACHINEKEY_DecryptionMACHINEKEY_DecryptionKeyMACHINEKEY_ValidationKeyMACHINEKEY_Validation を探し ます。You can find these keys in your container by looking for the following environment variables: MACHINEKEY_Decryption, MACHINEKEY_DecryptionKey, MACHINEKEY_ValidationKey, MACHINEKEY_Validation.

各再起動時の新しいキーによって ASP.NET フォーム認証とビュー状態がリセットされることがあります (それらにアプリが依存している場合)。The new keys at each restart may reset ASP.NET forms authentication and view state, if your app depends on them. キーが自動的に再生成されないようにするには、それらを App Service アプリ設定として手動で設定しますTo prevent the automatic regeneration of keys, set them manually as App Service app settings.

コンテナーに接続するConnect to the container

診断タスクのために Windows コンテナーに直接接続するには、https://<app-name>.scm.azurewebsites.net/DebugConsole に移動します。You can connect to your Windows container directly for diagnostic tasks by navigating to https://<app-name>.scm.azurewebsites.net/DebugConsole. しくみは次のとおりです。Here's how it works:

  • デバッグ コンソールでは、PowerShell セッションの開始、レジストリ キーの検査、コンテナー ファイル システム全体での移動など、対話型のコマンドを実行できます。The debug console lets you execute interactive commands, such as starting PowerShell sessions, inspecting registry keys, and navigate the entire container file system.
  • その上にあるグラフィカル ブラウザー (共有ストレージ内のファイルのみを表示) とは別に機能します。It functions separately from the graphical browser above it, which only shows the files in your shared storage.
  • スケールアウトされたアプリでは、デバッグ コンソールはコンテナー インスタンスのいずれかに接続されています。In a scaled-out app, the debug console is connected to one of the container instances. 上部のメニューの [インスタンス] ドロップダウンから別のインスタンスを選択できます。You can select a different instance from the Instance dropdown in the top menu.
  • コンソール内からコンテナーに対して行った変更は、Docker イメージの一部ではないため、アプリの再起動時には存続 " しません " (共有ストレージ内の変更は除きます)。Any change you make to the container from within the console does not persist when your app is restarted (except for changes in the shared storage), because it's not part of the Docker image. レジストリ設定やソフトウェアのインストールなどの変更を保持するには、Dockerfile の一部にします。To persist your changes, such as registry settings and software installation, make them part of the Dockerfile.

診断ログにアクセスするAccess diagnostic logs

App Service は、Docker ホストによるアクションと、コンテナー内からのアクティビティをログします。App Service logs actions by the Docker host as well as activities from within the container. Docker ホストからのログ (プラットフォーム ログ) は既定で送られますが、コンテナー内からのアプリケーション ログや Web サーバー ログは手動で有効にする必要があります。Logs from the Docker host (platform logs) are shipped by default, but application logs or web server logs from within the container need to be enabled manually. 詳細については、「アプリケーションのログ記録を有効にする」と「Web サーバーのログ記録を有効にする」を参照してください。For more information, see Enable application logging and Enable web server logging.

Docker ログにアクセスするには、いくつかの方法があります。There are several ways to access Docker logs:

Azure PortalIn Azure portal

Docker ログは、ポータル内のご自分のアプリの [コンテナーの設定] ページに表示されます。Docker logs are displayed in the portal, in the Container Settings page of your app. ログは切り捨てられますが、 [ダウンロード] をクリックしてすべてのログをダウンロードすることができます。The logs are truncated, but you can download all the logs clicking Download.

Kudu コンソールからFrom the Kudu console

https://<app-name>.scm.azurewebsites.net/DebugConsole に移動し、 LogFiles フォルダーをクリックして、個々のログ ファイルを表示します。Navigate to https://<app-name>.scm.azurewebsites.net/DebugConsole and click the LogFiles folder to see the individual log files. LogFiles ディレクトリ全体をダウンロードするには、ディレクトリ名の左側にある ダウンロード アイコンをクリックします。To download the entire LogFiles directory, click the Download icon to the left of the directory name. このフォルダーには、FTP クライアントを使用してアクセスすることもできます。You can also access this folder using an FTP client.

コンソール ターミナルでは、永続的な共有ストレージが有効になっていないため、既定では C:\home\LogFiles フォルダーにアクセスできません。In the console terminal, you can't access the C:\home\LogFiles folder by default because persistent shared storage is not enabled. コンソール ターミナルでこの動作を有効にするには、永続的な共有ストレージを有効にしますTo enable this behavior in the console terminal, enable persistent shared storage.

FTP クライアントを使用して現在使用中の Docker ログをダウンロードしようとすると、ファイル ロックが原因でエラーが発生することがあります。If you try to download the Docker log that is currently in use using an FTP client, you may get an error because of a file lock.

Kudu API を使用するWith the Kudu API

https://<app-name>.scm.azurewebsites.net/api/logs/docker に直接移動して、Docker ログのメタデータを表示します。Navigate directly to https://<app-name>.scm.azurewebsites.net/api/logs/docker to see metadata for the Docker logs. 複数のログ ファイルが表示される場合があります。また、href プロパティを使用すると、ログ ファイルを直接ダウンロードできます。You may see more than one log file listed, and the href property lets you download the log file directly.

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

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

既定では Azure App Service にデプロイされるすべての Windows コンテナーは、1 GB の RAM に制限されます。By default all Windows Containers deployed in Azure App Service are limited to 1 GB RAM. この値を変更するには、Cloud Shell を使用して WEBSITE_MEMORY_LIMIT_MB アプリ設定を指定します。You can change this value by providing the WEBSITE_MEMORY_LIMIT_MB app setting via the Cloud Shell. Bash では次のとおりです。In Bash:

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

PowerShell では次のとおりです。In PowerShell:

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

この値は MB 単位で定義されており、ホストの合計物理メモリ以下である必要があります。The value is defined in MB and must be less and equal to the total physical memory of the host. たとえば、8 GB の RAM を備えた App Service プランでは、すべてのアプリの累積合計 WEBSITE_MEMORY_LIMIT_MB が 8 GB を超えないようにする必要があります。For example, in an App Service plan with 8 GB RAM, the cumulative total of WEBSITE_MEMORY_LIMIT_MB for all the apps must not exceed 8 GB. 各価格レベルで使用できるメモリ量に関する情報については、「 App Service の価格」の Premium コンテナー (Windows) プラン に関するセクションを参照してください。Information on how much memory is available for each pricing tier can be found in App Service pricing, in the Premium Container (Windows) Plan section.

コンピューティング コアの数をカスタマイズするCustomize the number of compute cores

既定では、Windows コンテナーは、選択した価格レベルで使用できるすべてのコアで実行されます。By default, a Windows container runs with all available cores for your chosen pricing tier. たとえば、ステージング スロットで使用されるコアの数を減らすことができます。You may want to reduce the number of cores that your staging slot uses, for example. コンテナーによって使用されるコアの数を減らすには、WEBSITE_CPU_CORES_LIMIT アプリ設定を、希望するコア数に設定します。To reduce the number of cores used by a container, set the WEBSITE_CPU_CORES_LIMIT app setting to the preferred number of cores. これは、Cloud Shell を使用して設定できます。You can set it via the Cloud Shell. Bash では次のとおりです。In Bash:

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

PowerShell では次のとおりです。In PowerShell:

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

注意

アプリ設定を更新すると、自動再起動がトリガーされ、ダウンタイムが最小限に抑えられます。Updating the app setting triggers automatic restart, causing minimal downtime. 運用アプリの場合は、それをステージング スロットに入れ替え、ステージング スロットでアプリ設定を変更してから、運用環境に戻すことを検討してください。For a production app, consider swapping it into a staging slot, change the app setting in the staging slot, and then swap it back into production.

Kudu コンソール (https://<app-name>.scm.azurewebsites.net) に移動して、PowerShell を使用して次のコマンドを入力し、調整された数を確認します。Verify your adjusted number by going to the Kudu Console (https://<app-name>.scm.azurewebsites.net) and typing in the following commands using PowerShell. 各コマンドは数値を出力します。Each command outputs a number.

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

プロセッサは、マルチコアまたはハイパースレッディングのプロセッサにすることができます。The processors may be multicore or hyperthreading processors. 各価格レベルで使用できるコア数に関する情報については、「 App Service の価格」の Premium コンテナー (Windows) プラン に関するセクションを参照してください。Information on how many cores are available for each pricing tier can be found in App Service pricing, in the Premium Container (Windows) Plan section.

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

App Service では、コンテナーが開始して HTTP ping に応答すると、コンテナーが正常に開始したと見なされます。App Service considers a container to be successfully started when the container starts and responds to an HTTP ping. 正常性 ping 要求には、ヘッダー User-Agent= "App Service Hyper-V Container Availability Check" が含まれています。The health ping request contains the header User-Agent= "App Service Hyper-V Container Availability Check". コンテナーが起動したが、一定の時間が経過しても ping に応答しない場合、App Service は、コンテナーが起動しなかったことを示すイベントを Docker ログに記録します。If the container starts but does not respond to a ping after a certain amount of time, App Service logs an event in the Docker log, saying that the container didn't start.

アプリケーションがリソースを大量に消費する場合、コンテナーは時間内に HTTP ping に応答しない可能性があります。If your application is resource-intensive, the container might not respond to the HTTP ping in time. HTTP ping が失敗したときのアクションを制御するには、CONTAINER_AVAILABILITY_CHECK_MODE アプリ設定を指定します。To control the actions when HTTP pings fail, set the CONTAINER_AVAILABILITY_CHECK_MODE app setting. これは、Cloud Shell を使用して設定できます。You can set it via the Cloud Shell. Bash では次のとおりです。In Bash:

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

PowerShell では次のとおりです。In PowerShell:

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

指定可能な値を次の表に示します。The following table shows the possible values:

[値]Value 説明Descriptions
修復Repair 3 回連続して可用性チェックを実行した後にコンテナーを再起動するRestart the container after three consecutive availability checks
ReportOnlyReportOnly 既定値。The default value. コンテナーを再起動しないが、3 回連続して可用性チェックを実行した後、そのコンテナーについて Docker ログに報告します。Don't restart the container but report in the Docker logs for the container after three consecutive availability checks.
" オフ "Off 可用性を確認しません。Don't check for availability.

グループの管理されたサービス アカウントのサポートSupport for Group Managed Service Accounts

グループの管理されたサービス アカウント (gMSA) は現在、App Service の Windows コンテナーではサポートされていません。Group Managed Service Accounts (gMSAs) are currently not supported in Windows containers in App Service.

SSH を有効にするEnable SSH

SSH では、コンテナーとクライアント間の通信をセキュリティで保護できます。SSH enables secure communication between a container and a client. カスタム コンテナーで SSH をサポートするために、Dockerfile 自体に追加する必要があります。In order for a custom container to support SSH, you must add it into the Dockerfile itself.

ヒント

すべての組み込み Linux コンテナーは、そのイメージ リポジトリ内に SSH 命令を追加しました。All built-in Linux containers have added the SSH instructions in their image repositories. Node.js 10.14 リポジトリで次のとおり実行し、それをそこで有効にする方法を表示できます。You can go through the following instructions with the Node.js 10.14 repository to see how it's enabled there.

  • RUN 命令を使用して、SSH サーバーをインストールし、ルート アカウントのパスワードを "Docker!" に設定します。Use the RUN instruction to install the SSH server and set the password for the root account to "Docker!". たとえば、Alpine Linux に基づくイメージの場合、次のコマンドが必要です。For example, for an image based on Alpine Linux, you need the following commands:

    RUN apk add openssh \
         && echo "root:Docker!" | chpasswd 
    

    この構成は、コンテナーへの外部接続を許可しません。This configuration doesn't allow external connections to the container. SSH は https://<app-name>.scm.azurewebsites.net を通じてのみ利用でき、公開用の資格情報で認証されます。SSH is available only through https://<app-name>.scm.azurewebsites.net and authenticated with the publishing credentials.

  • この sshd_config ファイルをイメージ リポジトリに追加し、 COPY 命令を使用してファイルを /etc/ssh/ ディレクトリにコピーします。Add this sshd_config file to your image repository, and use the COPY instruction to copy the file to the /etc/ssh/ directory. sshd_config ファイルの詳細については、 OpenBSD ドキュメントを参照してください。For more information about sshd_config files, see OpenBSD documentation.

    COPY sshd_config /etc/ssh/
    

    注意

    sshd_config ファイルには次の項目を指定する必要があります。The sshd_config file must include the following items:

    • Ciphers には、aes128-cbc,3des-cbc,aes256-cbc の項目を少なくとも 1 つ含める必要があります。Ciphers must include at least one item in this list: aes128-cbc,3des-cbc,aes256-cbc.
    • MACs には、hmac-sha1,hmac-sha1-96 の項目を少なくとも 1 つ含める必要があります。MACs must include at least one item in this list: hmac-sha1,hmac-sha1-96.
  • EXPOSE 命令を使用して、コンテナーでポート 2222 を開きます。Use the EXPOSE instruction to open port 2222 in the container. ルート パスワードはわかっていますが、ポート 2222 にはインターネットからアクセスできません。Although the root password is known, port 2222 is inaccessible from the internet. それには、プライベート仮想ネットワークのブリッジ ネットワーク内でコンテナーのみがアクセスできます。It's accessible only by containers within the bridge network of a private virtual network.

    EXPOSE 80 2222
    
  • コンテナーのスタートアップ スクリプトで、SSH サーバーを起動します。In the start-up script for your container, start the SSH server.

    /usr/sbin/sshd
    

    例については、既定の Node.js 10.14 コンテナーが SSH サーバーを起動する方法を参照してください。For an example, see how the default Node.js 10.14 container starts the SSH server.

診断ログにアクセスするAccess diagnostic logs

コンテナー内から生成されたコンソール ログにアクセスできます。You can access the console logs generated from inside the container.

まず、次のコマンドを実行して、コンテナーのログ記録をオンにします。First, turn on container logging by running the following command:

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

<app-name><resource-group-name> は、Web アプリに適した名前に置き換えます。Replace <app-name> and <resource-group-name> with the names appropriate for your web app.

コンテナーのログ記録がオンになったら、次のコマンドを実行して、ログのストリームを確認します。Once container logging is turned on, run the following command to see the log stream:

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

コンソール ログがすぐに表示されない場合は、30 秒以内にもう一度確認します。If you don't see console logs immediately, check again in 30 seconds.

任意のタイミングでログのストリーミングを停止するには、 Ctrl+C キーを押します。To stop log streaming at any time, type Ctrl+C .

ブラウザーから https://<app-name>.scm.azurewebsites.net/api/logs/docker でログ ファイルを検査することもできます。You can also inspect the log files in a browser at https://<app-name>.scm.azurewebsites.net/api/logs/docker.

複数コンテナー アプリを構成するConfigure multi-container apps

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

WordPress のような複数コンテナー アプリでは、永続的ストレージが適切に機能する必要があります。Multi-container apps like WordPress need persistent storage to function properly. 有効にするには、Docker Compose 構成が、コンテナー の保存場所を指す必要があります。To enable it, your Docker Compose configuration must point to a storage location outside your container. コンテナー内部の保存場所では、アプリの再起動後に変更内容が保持されません。Storage locations inside your container don't persist changes beyond app restart.

Cloud Shellaz webapp config appsettings set コマンドを使用して、WEBSITES_ENABLE_APP_SERVICE_STORAGE アプリ設定を指定することで、永続的ストレージを有効にします。Enable persistent storage by setting the WEBSITES_ENABLE_APP_SERVICE_STORAGE app setting, using the az webapp config appsettings set command in Cloud Shell.

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} にマップします。In your docker-compose.yml file, map the volumes option to ${WEBAPP_STORAGE_HOME}.

WEBAPP_STORAGE_HOME は、アプリの永続的なストレージにマップされる App Service の環境変数です。WEBAPP_STORAGE_HOME is an environment variable in App Service that is mapped to persistent storage for your app. 次に例を示します。For example:

wordpress:
  image: wordpress:latest
  volumes:
  - ${WEBAPP_STORAGE_HOME}/site/wwwroot:/var/www/html
  - ${WEBAPP_STORAGE_HOME}/phpmyadmin:/var/www/phpmyadmin
  - ${WEBAPP_STORAGE_HOME}/LogFiles:/var/log

プレビューの制限事項Preview limitations

複数コンテナーは現在プレビュー段階です。Multi-container is currently in preview. 次の App Service プラットフォーム機能はサポートされません。The following App Service platform features are not supported:

  • 認証/認可Authentication / Authorization
  • マネージド IDManaged Identities
  • CORSCORS

Docker Compose のオプションDocker Compose options

以下の一覧は、Docker Compose 構成オプションでサポートされているものとサポートされていないものを示しています。The following lists show supported and unsupported Docker Compose configuration options:

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

  • commandcommand
  • entrypointentrypoint
  • 環境environment
  • imageimage
  • portsports
  • restartrestart
  • servicesservices
  • volumesvolumes

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

  • build (禁止)build (not allowed)
  • depends_on (無視)depends_on (ignored)
  • networks (無視)networks (ignored)
  • secrets (無視)secrets (ignored)
  • ports (80 および 8080 以外) (無視)ports other than 80 and 8080 (ignored)

注意

パブリック プレビューでは、ここで明示的に示されていないその他のオプションが無視されます。Any other options not explicitly called out are ignored in Public Preview.

ログの robots933456robots933456 in logs

コンテナー ログで次のメッセージが表示されることがあります。You may see the following message in the container logs:

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

このメッセージは無視してかまいません。You can safely ignore this message. /robots933456.txt は、コンテナーが要求を処理できるかどうかを調べるために App Service が使用するダミーの URL パスです。/robots933456.txt is a dummy URL path that App Service uses to check if the container is capable of serving requests. 404 応答は、パスが存在しないことを示すだけですが、コンテナーが正常であり、要求に応答できる状態であることを App Service に知らせます。A 404 response simply indicates that the path doesn't exist, but it lets App Service know that the container is healthy and ready to respond to requests.

次のステップNext steps

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

Windows/Linux コンテナーで証明書を読み込むLoad certificate in Windows/Linux containers