Azure Container Instances における、トラブルシューティングに関する一般的問題Troubleshoot common issues in Azure Container Instances

この記事では、Azure Container Instances を管理し、またはこれ にコンテナーをデプロイする際の、一般的問題をトラブルシューティングする方法を示します。This article shows how to troubleshoot common issues for managing or deploying containers to Azure Container Instances.

名前付け規則Naming conventions

コンテナーの仕様を定義するときに、特定のパラメーターは名前付けの制限に準拠している必要があります。When defining your container specification, certain parameters require adherence to naming restrictions. 下記は、コンテナーグループの特性のための、特定の要件を持つテーブルです。Below is a table with specific requirements for container group properties. Azure の名前付け規則の詳細については、Azure Architecture Center 内の名前付け規則を参照してください。For more information on Azure naming conventions, see Naming conventions in the Azure Architecture Center.

Scope (スコープ)Scope LengthLength 大文字小文字の区別Casing 有効な文字Valid characters 提案されるパターンSuggested pattern Example
コンテナー グループ名Container group name 1 ~ 641-64 大文字と小文字は区別されないCase insensitive 最初と最後の文字を除く任意の場所の英数字とハイフンAlphanumeric, and hyphen anywhere except the first or last character <name>-<role>-CG<number> web-batch-CG1
コンテナー名Container name 1 ~ 641-64 大文字と小文字は区別されないCase insensitive 最初と最後の文字を除く任意の場所の英数字とハイフンAlphanumeric, and hyphen anywhere except the first or last character <name>-<role>-CG<number> web-batch-CG1
コンテナーポートContainer ports 1 ~ 65535 の範囲Between 1 and 65535 整数Integer 1 ~ 65535 の整数Integer between 1 and 65535 <port-number> 443
DNS 名ラベルDNS name label 5-635-63 大文字と小文字は区別されないCase insensitive 最初と最後の文字を除く任意の場所の英数字とハイフンAlphanumeric, and hyphen anywhere except the first or last character <name> frontend-site1
環境変数Environment variable 1 ~ 631-63 大文字と小文字は区別されないCase insensitive 最初と最後の文字を除く任意の場所の英数字とアンダースコア ()Alphanumeric, and underscore () anywhere except the first or last character <name> MY_VARIABLE
ボリューム名Volume name 5-635-63 大文字と小文字は区別されないCase insensitive 最初と最後の文字を除く任意の場所の小文字のアルファベット、数字、およびハイフン。Lowercase letters and numbers, and hyphens anywhere except the first or last character. 2つの連続するハイフンを含めることはできません。Cannot contain two consecutive hyphens. <name> batch-output-volume

イメージの OS バージョンがサポートされていないOS version of image not supported

Azure Container Instances でサポートされていないイメージを指定した場合は、OsVersionNotSupported エラーが返されます。If you specify an image that Azure Container Instances doesn't support, an OsVersionNotSupported error is returned. エラーは次のようになり、{0} はデプロイしようとしたイメージの名前です。The error is similar to following, where {0} is the name of the image you attempted to deploy:

{
  "error": {
    "code": "OsVersionNotSupported",
    "message": "The OS version of image '{0}' is not supported."
  }
}

このエラーは、半期チャネル (SAC) リリースに基づく Windows イメージを展開するときに最も多く発生します。This error is most often encountered when deploying Windows images that are based on a Semi-Annual Channel (SAC) release. たとえば、Windows バージョン 1709 および 1803 は SAC リリースであり、展開時にこのエラーを生成します。For example, Windows versions 1709 and 1803 are SAC releases, and generate this error upon deployment.

Azure Container Instances は現在、Windows Server 2016 の長期的なサービス チャネル (LTSC) リリースにのみ基づいた Windows イメージをサポートしています。Azure Container Instances currently supports Windows images based only on the Windows Server 2016 Long-Term Servicing Channel (LTSC) release. Windows コンテナーのデプロイ時にこの問題を軽減するには、常に Windows Server 2016 (LTSC) ベースのイメージをデプロイしてください。To mitigate this issue when deploying Windows containers, always deploy Windows Server 2016 (LTSC)-based images. Windows Server 2019 (LTSC) に基づいたイメージはサポートされていません。Images based on Windows Server 2019 (LTSC) are not supported.

Windows の LTSC および SAC バージョンについて詳しくは、「Windows Server の半期チャネルの概要」をご覧ください。For details about the LTSC and SAC versions of Windows, see Windows Server Semi-Annual Channel overview.

イメージをプルできないUnable to pull image

Azure Container Instances は、最初にイメージをプルできなかった場合に、一定期間再試行します。If Azure Container Instances is initially unable to pull your image, it retries for a period of time. イメージのプル操作の失敗が続く場合、ACI は最終的に展開に失敗し、Failed to pull image エラーが表示されることがあります。If the image pull operation continues to fail, ACI eventually fails the deployment, and you may see a Failed to pull image error.

この問題を解決するには、コンテナー インスタンスを削除し、展開を再試行します。To resolve this issue, delete the container instance and retry your deployment. イメージがレジストリに存在し、イメージの名前を正しく入力したことをご確認ください。Ensure that the image exists in the registry, and that you've typed the image name correctly.

イメージをプルできない場合は、az container show の出力に次のようなイベントが表示されます。If the image can't be pulled, events like the following are shown in the output of az container show:

"events": [
  {
    "count": 3,
    "firstTimestamp": "2017-12-21T22:56:19+00:00",
    "lastTimestamp": "2017-12-21T22:57:00+00:00",
    "message": "pulling image \"microsoft/aci-hellowrld\"",
    "name": "Pulling",
    "type": "Normal"
  },
  {
    "count": 3,
    "firstTimestamp": "2017-12-21T22:56:19+00:00",
    "lastTimestamp": "2017-12-21T22:57:00+00:00",
    "message": "Failed to pull image \"microsoft/aci-hellowrld\": rpc error: code 2 desc Error: image t/aci-hellowrld:latest not found",
    "name": "Failed",
    "type": "Warning"
  },
  {
    "count": 3,
    "firstTimestamp": "2017-12-21T22:56:20+00:00",
    "lastTimestamp": "2017-12-21T22:57:16+00:00",
    "message": "Back-off pulling image \"microsoft/aci-hellowrld\"",
    "name": "BackOff",
    "type": "Normal"
  }
],

コンテナーが絶えず終了して再起動する (長時間実行されるプロセスがない)Container continually exits and restarts (no long-running process)

コンテナー グループは再起動ポリシーが既定で Always に設定されるため、コンテナー グループ内のコンテナーは実行完了後に必ず再起動します。Container groups default to a restart policy of Always, so containers in the container group always restart after they run to completion. タスクベースのコンテナーを実行する場合は、これを OnFailure または Never に変更することが必要になることがあります。You may need to change this to OnFailure or Never if you intend to run task-based containers. OnFailure を指定してもそのまま再起動された場合、お使いのコンテナーで実行されるアプリケーションまたはスクリプトに問題が生じている可能性があります。If you specify OnFailure and still see continual restarts, there might be an issue with the application or script executed in your container.

Ubuntu や Alpine などのイメージを使用した場合、長時間実行されるプロセスのないコンテナー グループを実行していると、終了と再起動が繰り返されることがあります。When running container groups without long-running processes you may see repeated exits and restarts with images such as Ubuntu or Alpine. コンテナーを実行したままにするプロセスがないため、EXEC を使った接続は機能しません。Connecting via EXEC will not work as the container has no process keeping it alive. これを解決するには、コンテナー グループのデプロイに次のような起動コマンドを含め、コンテナーを実行したままにします。To resolve this include a start command like the following with your container group deployment to keep the container running.

## Deploying a Linux container
az container create -g MyResourceGroup --name myapp --image ubuntu --command-line "tail -f /dev/null"
## Deploying a Windows container
az container create -g myResourceGroup --name mywindowsapp --os-type Windows --image microsoft/windowsservercore:ltsc2016
 --command-line "ping -t localhost"

Container Instances API と Azure portal には restartCount プロパティが含まれています。The Container Instances API and Azure portal includes a restartCount property. コンテナーの再起動の回数を確認するには、Azure CLI の az container show コマンドを使用できます。To check the number of restarts for a container, you can use the az container show command in the Azure CLI. 次の出力例 (簡略化のため一部のみ) では、出力の末尾に restartCount プロパティを確認できます。In the following example output (which has been truncated for brevity), you can see the restartCount property at the end of the output.

...
 "events": [
   {
     "count": 1,
     "firstTimestamp": "2017-11-13T21:20:06+00:00",
     "lastTimestamp": "2017-11-13T21:20:06+00:00",
     "message": "Pulling: pulling image \"myregistry.azurecr.io/aci-tutorial-app:v1\"",
     "type": "Normal"
   },
   {
     "count": 1,
     "firstTimestamp": "2017-11-13T21:20:14+00:00",
     "lastTimestamp": "2017-11-13T21:20:14+00:00",
     "message": "Pulled: Successfully pulled image \"myregistry.azurecr.io/aci-tutorial-app:v1\"",
     "type": "Normal"
   },
   {
     "count": 1,
     "firstTimestamp": "2017-11-13T21:20:14+00:00",
     "lastTimestamp": "2017-11-13T21:20:14+00:00",
     "message": "Created: Created container with id bf25a6ac73a925687cafcec792c9e3723b0776f683d8d1402b20cc9fb5f66a10",
     "type": "Normal"
   },
   {
     "count": 1,
     "firstTimestamp": "2017-11-13T21:20:14+00:00",
     "lastTimestamp": "2017-11-13T21:20:14+00:00",
     "message": "Started: Started container with id bf25a6ac73a925687cafcec792c9e3723b0776f683d8d1402b20cc9fb5f66a10",
     "type": "Normal"
   }
 ],
 "previousState": null,
 "restartCount": 0
...
}

注意

Linux ディストリビューションのほとんどのコンテナー イメージは、既定のコマンドとして、bash などのシェルを設定します。Most container images for Linux distributions set a shell, such as bash, as the default command. 独自のシェルは実行時間の長いサービスではないため、既定の [常時] 再起動ポリシーを利用して構成された場合、これらのコンテナーはすぐに終了し、再起動ループ状態に陥ります。Since a shell on its own is not a long-running service, these containers immediately exit and fall into a restart loop when configured with the default Always restart policy.

コンテナーの起動に時間がかかるContainer takes a long time to start

Azure Container Instances のコンテナーの起動時間に関係する 2 つの主な要素を、次に示します。The two primary factors that contribute to container startup time in Azure Container Instances are:

Windows イメージには、追加の考慮事項があります。Windows images have additional considerations.

イメージ サイズImage size

コンテナーが起動するまで時間がかかるが、最終的に起動する場合は、コンテナー イメージのサイズを調べることから始めてください。If your container takes a long time to start, but eventually succeeds, start by looking at the size of your container image. Azure Container Instances は、要求に応じてコンテナー イメージをプルするため、起動時間はそのサイズと直接的に関係しています。Because Azure Container Instances pulls your container image on demand, the startup time you see is directly related to its size.

コンテナー イメージのサイズは、Docker CLI で docker images コマンドを使用することで表示できます。You can view the size of your container image by using the docker images command in the Docker CLI:

$ docker images
REPOSITORY                  TAG       IMAGE ID        CREATED        SIZE
microsoft/aci-helloworld    latest    7f78509b568e    13 days ago    68.1MB

イメージのサイズを小さくしておくための鍵は、最終イメージに実行時に不要なものが含まれないようにすることです。The key to keeping image sizes small is ensuring that your final image does not contain anything that is not required at runtime. これを行う 1 つの方法は、マルチステージ ビルドを使用することです。One way to do this is with multi-stage builds. マルチステージ ビルドを使用すると、最終イメージにはアプリケーションに必要な成果物のみが含まれ、ビルド時に必要であった余分なコンテンツは含まれないようにすることを簡単に実行できます。Multi-stage builds make it easy to ensure that the final image contains only the artifacts you need for your application, and not any of the extra content that was required at build time.

イメージの場所Image location

コンテナーの起動時に発生するイメージ プルの影響を軽減する別の方法は、コンテナー インスタンスをデプロイする予定のリージョンと同じリージョン内の Azure Container Registry で、コンテナー イメージをホストすることです。Another way to reduce the impact of the image pull on your container's startup time is to host the container image in Azure Container Registry in the same region where you intend to deploy container instances. これにより、コンテナー イメージを伝送する必要があるネットワーク パスが短縮され、ダウンロード時間が大幅に短くなります。This shortens the network path that the container image needs to travel, significantly shortening the download time.

キャッシュされた Windows イメージCached Windows images

Azure Container Instances では、キャッシュ メカニズムを使用して、特定の Windows イメージに基づくイメージに対するコンテナーの起動時間を高速化します。Azure Container Instances uses a caching mechanism to help speed container startup time for images based on certain Windows images.

Windows コンテナーの起動時間を最速にするには、次の 2 つのイメージ最新の 3 つのバージョンのいずれかを、基本イメージとして使用します。To ensure the fastest Windows container startup time, use one of the three most recent versions of the following two images as the base image:

Windows コンテナーの低速のネットワークの準備Windows containers slow network readiness

接続の初期作成時に、最大で 30 秒間 (まれではありますがさらに長くなることもあります)、Windows コンテナーに受信または送信の接続ができない場合があります。On initial creation, Windows containers may have no inbound or outbound connectivity for up to 30 seconds (or longer, in rare cases). コンテナー アプリケーションにインターネット接続が必要な場合は、遅延を加えてロジックを再試行し、30 秒間でインターネット接続を確立できるようにします。If your container application needs an Internet connection, add delay and retry logic to allow 30 seconds to establish Internet connectivity. 初期セットアップ後に、コンテナーのネットワークが適切に再開する必要があります。After initial setup, container networking should resume appropriately.

リソース使用不可エラーResource not available error

Azure ではリージョンによってリソースの読み込みに変化があるため、コンテナー インスタンスをデプロイしようとすると、以下のエラーが表示される場合があります。Due to varying regional resource load in Azure, you might receive the following error when attempting to deploy a container instance:

The requested resource with 'x' CPU and 'y.z' GB memory is not available in the location 'example region' at this moment. Please retry with a different resource request or in another location.

このエラーは、デプロイを試行しているリージョンで高負荷になっているため、コンテナーに指定されたリソースが、その時点では割り当てできないことを示しています。This error indicates that due to heavy load in the region in which you are attempting to deploy, the resources specified for your container can't be allocated at that time. 以下に示す 1 つ以上の軽減策の手順を使用して、問題を解決してください。Use one or more of the following mitigation steps to help resolve your issue.

  • コンテナーのデプロイ設定が、「Quotas and region availability for Azure Container Instances」 (Azure Container Instances のクォータとリージョンの可用性) で定義されているパラメーター内に収まっていることを確認するVerify your container deployment settings fall within the parameters defined in Quotas and region availability for Azure Container Instances
  • コンテナーに低い CPU およびメモリ設定を指定する。Specify lower CPU and memory settings for the container
  • 別の Azure リージョンにデプロイするDeploy to a different Azure region
  • 後でデプロイするDeploy at a later time

基になる Docker API に接続できないか、特権コンテナーを実行できないCannot connect to underlying Docker API or run privileged containers

Azure Container Instances は、コンテナー グループをホストする、基になるインフラストラクチャへの直接アクセスを公開しません。Azure Container Instances does not expose direct access to the underlying infrastructure that hosts container groups. これには、コンテナーのホストで実行されている Docker API へのアクセスと、実行中の特権コンテナーへのアクセスが含まれます。This includes access to the Docker API running on the container's host and running privileged containers. Docker の相互作用が必要な場合は、REST リファレンス ドキュメントを参照して、ACI API でサポートされるものをご確認ください。If you require Docker interaction, check the REST reference documentation to see what the ACI API supports. 不足しているものがある場合は、ACI フィードバック フォーラムに要求を送信します。If there is something missing, submit a request on the ACI feedback forums.

ポートが一致しないために IP にアクセスできないIPs may not be accessible due to mismatched ports

現在、Azure Container Instances は、通常の docker 構成のようなポート マッピングをサポートしていませんが、この修正はロードマップにあります。Azure Container Instances does not currently support port mapping like with regular docker configuration, however this fix is on the roadmap. IP にアクセスできるはずの場合にアクセスできない場合は、ports プロパティを使用してコンテナー グループで公開しているものと同じポートをリッスンするようにコンテナー イメージを構成してください。If you find IPs are not accessible when you believe it should be, ensure you have configured your container image to listen to the same ports you expose in your container group with the ports property.

次の手順Next steps

コンテナーのデバッグを支援するために、コンテナーのログとイベントを取得する方法を学びました。Learn how to retrieve container logs & events to help debug your containers.