Azure Container Instances の一般的な問題のトラブルシューティング

この記事では、Azure Container Instances を管理し、またはこれにコンテナーをデプロイする際の、一般的問題をトラブルシューティングする方法を示します。よく寄せられる質問も参照してください。

さらにサポートが必要な場合は、Azure portal で利用可能な [ヘルプとサポート] オプションをご覧ください。

コンテナーグループのデプロイ時に発生する問題

名前付け規則

コンテナーの仕様を定義するときに、特定のパラメーターは名前付けの制限に準拠している必要があります。次の表は、コンテナーグループのプロパティの具体的な要件を示しています。詳細については、Azure アーキテクチャセンターの「名前付け規則」と、「Azure リソースの名前付け規則と制限事項」を参照してください。

Scope	長さ	大文字小文字の区別	有効な文字	提案されるパターン	例
コンテナー名¹	1 ～ 63	小文字	英数字、および先頭または末尾以外の任意の位置で使用できるハイフン	`<name>-<role>-container<number>`	`web-batch-container1`
コンテナーポート	1 ～ 65535 の範囲	整数	1 ～ 65535 の整数	`<port-number>`	`443`
DNS 名ラベル	5-63	大文字と小文字を区別しない	英数字、および先頭または末尾以外の任意の位置で使用できるハイフン	`<name>`	`frontend-site1`
環境変数	1 ～ 63	大文字と小文字を区別しない	最初と最後の文字を除く任意の場所の英数字とアンダースコア (_)	`<name>`	`MY_VARIABLE`
ボリューム名	5-63	小文字	先頭または末尾の文字を除き、英数字とハイフンを使用できます。 2 つの連続するハイフンを含めることはできません。	`<name>`	`batch-output-volume`

¹コンテナーインスタンスとは独立して指定されていない場合 (az container create コマンドの展開など)、コンテナーグループ名にも制限がかかります。

イメージの OS バージョンがサポートされていない

Azure Container Instances でサポートされていないイメージを指定した場合は、OsVersionNotSupported エラーが返されます。エラーは次のようになり、{0} はデプロイしようとしたイメージの名前です。

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

このエラーは、半期チャネルリリース 1709 または 1803 に基づく Windows イメージ (サポートされていないもの) をデプロイするときに最も多く発生します。 Azure Container Instances でサポートされている Windows イメージについては、よく寄せられる質問を参照してください。

イメージをプルできない

Azure Container Instances は、最初にイメージをプルできなかった場合に、時間をおいて再試行します。イメージのプル操作の失敗が続く場合、ACI は最終的に展開に失敗し、Failed to pull image エラーが表示されることがあります。

この問題を解決するには、コンテナーインスタンスを削除し、展開を再試行します。イメージがレジストリに存在し、イメージの名前を正しく入力したことをご確認ください。

Important

ACI では、プライベートエンドポイントとマネージド ID で Azure Container Registry (ACR) を使用する場合にのみ、プライベートレジストリ (パブリック IP のないレジストリ) からのイメージのプルがサポートされます。 ACI とレジストリの間で仮想ネットワーク接続が構成されている場合でも、ACR 以外のプライベートレジストリからのイメージのプルはサポートされていません。プライベートレジストリを使用する必要がある場合は、イメージを ACR に移行し、マネージド ID を使用してプライベートエンドポイントを構成します。詳細については、「仮想ネットワークのシナリオとリソース - サポートされていないネットワークシナリオ」を参照してください。

イメージをプルできない場合は、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 \"mcr.microsoft.com/azuredocs/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 \"mcr.microsoft.com/azuredocs/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 \"mcr.microsoft.com/azuredocs/aci-hellowrld\"",
    "name": "BackOff",
    "type": "Normal"
  }
],

リソース使用不可エラー

Azure ではリージョンによってリソースの読み込みに変化があるため、コンテナーインスタンスをデプロイしようとすると、以下のエラーが表示される場合があります。

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.

このエラーは、デプロイを試行しているリージョンで高負荷になっているため、コンテナーに指定されたリソースが、その時点では割り当てできないことを示しています。以下に示す 1 つ以上の軽減策の手順を使用して、問題を解決してください。

コンテナーのデプロイ設定が、Azure Container Instances のリージョンでの利用可否に関する記事で定義されているパラメーター内に収まっていることを確認する
コンテナーに低い CPU およびメモリ設定を指定する。
別の Azure リージョンにデプロイする
後でデプロイする

コンテナーグループの実行時に発生する問題

明示的なユーザー入力なしでコンテナーで分離再起動が行われた

コンテナーグループが明示的なユーザー入力なしで再起動する理由は、2 つのカテゴリに大別されます。まず、アプリケーションプロセスのクラッシュによってコンテナーが再起動する可能性があります。 ACI サービスでは、Application Insights SDK、コンテナーグループメトリック、コンテナーグループログなどの監視ソリューションを適用して、アプリケーションで問題が発生した理由を判別することをお薦めします。 2 つ目は、メンテナンスイベントのために ACI インフラストラクチャが開始する再起動を顧客が経験する可能性があります。アプリケーションの可用性を向上するには、複数のコンテナーグループを、Application Gateway または Traffic Manager のようなイングレスコンポーネントの背後で実行します。

コンテナが繰り返し終了と再起動を行う（継続的に実行されるプロセスがない）

コンテナーグループは再起動ポリシーが既定で Always に設定されるため、コンテナーグループ内のコンテナーは実行完了後に必ず再起動します。タスクベースのコンテナーを実行する場合は、これを OnFailure または Never に変更することが必要になることがあります。 OnFailure を指定してもそのまま再起動された場合、お使いのコンテナーで実行されるアプリケーションまたはスクリプトに問題が生じている可能性があります。

注

Never再起動ポリシーは、コンテナーが終了コード 0 で正常に終了した場合にのみ再起動を防止します。コンテナーが 0 以外の終了コードで終了した場合でも、プラットフォームで再起動される可能性があります。詳細については、「 0 以外の終了コードを使用した再起動動作」を参照してください。

Ubuntu や Alpine などのイメージを使用した場合、長時間実行されるプロセスのないコンテナーグループを実行していると、終了と再起動が繰り返されることがあります。コンテナーを実行したままにするプロセスがないため、EXEC を使った接続は機能しません。この問題を解決するには、コンテナーグループのデプロイに次の例のような起動コマンドを含め、コンテナーを実行したままにします。

## 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 mcr.microsoft.com/windows/servercore:ltsc2019
 --command-line "ping -t localhost"

Container Instances API と Azure portal には restartCount プロパティが含まれています。コンテナーの再起動の回数を確認するには、Azure CLI の az container show コマンドを使用できます。次の出力例 (簡潔にするために省略しています) には、出力の末尾に restartCount プロパティがあります。

...
 "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 などのシェルを設定します。独自のシェルは実行時間の長いサービスではないため、既定の [常時] 再起動ポリシーを利用して構成された場合、これらのコンテナーはすぐに終了し、再起動ループ状態に陥ります。

コンテナーの起動に時間がかかる

Azure Container Instances のコンテナーの起動時間に関係する 3 つの主な要素を、次に示します。

イメージサイズ
イメージの場所
キャッシュされたイメージ

Windows イメージには、その他の考慮事項もあります。

画像サイズ

コンテナーが起動するまで時間がかかるが、最終的に起動する場合は、コンテナーイメージのサイズを調べることから始めてください。 Azure Container Instances は、要求に応じてコンテナーイメージをプルするため、起動時間はそのサイズと直接的に関係しています。

コンテナーイメージのサイズは、Docker CLI で docker images コマンドを使用することで表示できます。

docker images

REPOSITORY                                    TAG       IMAGE ID        CREATED          SIZE
mcr.microsoft.com/azuredocs/aci-helloworld    latest    7367f3256b41    15 months ago    67.6MB

イメージのサイズを小さくしておくための鍵は、最終イメージに実行時に不要なものが含まれないようにすることです。これを行う 1 つの方法は、マルチステージビルドを使用することです。マルチステージビルドを使用すると、最終イメージにはアプリケーションに必要な成果物のみが含まれ、ビルド時に必要であった余分なコンテンツは含まれないようにすることを簡単に実行できます。

画像の場所

コンテナーの起動時に発生するイメージプルの影響を軽減する別の方法は、コンテナーインスタンスをデプロイする予定のリージョンと同じリージョン内の Azure Container Registry で、コンテナーイメージをホストすることです。これにより、コンテナーイメージを伝送する必要があるネットワークパスが短縮され、ダウンロード時間が大幅に短くなります。

キャッシュイメージ

Azure Container Instances では、nanoserver:1809、servercore:ltsc2019、servercore:1809 などの一般的なWindows ベースイメージ上に構築されたイメージについて、コンテナーの起動時間を短縮するためにキャッシュメカニズムを使用します。 ubuntu:1604 や alpine:3.6 など、よく使用される Linux イメージもキャッシュされます。 Windows と Linux の両方のイメージには、latest タグを使用しないようにしてください。ガイダンスについては、Container Registry のイメージタグのベストプラクティスに関する記事を参照してください。キャッシュされたイメージとタグの最新の一覧については、List Cached Images API を使用してください。

注

Azure Container Instances での Windows Server 2019 ベースのイメージの使用は、プレビュー段階です。

Windows コンテナーのネットワーク準備完了が遅い

接続の初期作成時に、最大で 30 秒間 (まれではありますがさらに長くなることもあります)、Windows コンテナーに受信または送信の接続ができない場合があります。コンテナーアプリケーションにインターネット接続が必要な場合は、遅延を加えてロジックを再試行し、30 秒間でインターネット接続を確立できるようにします。初期セットアップ後に、コンテナーのネットワークが適切に再開する必要があります。

基になる Docker API に接続できないか、特権コンテナーを実行できない

Azure Container Instances は、コンテナーグループをホストする、基になるインフラストラクチャへの直接アクセスを公開しません。これには、コンテナーランタイムへのアクセス、オーケストレーションテクノロジ、および特権コンテナー操作の実行が含まれます。 ACI でサポートされている操作を確認するには、REST のリファレンスドキュメントを参照してください。不足しているものがある場合は、ACI フィードバックフォーラムに要求を送信します。

ポートが一致しないため、コンテナーグループの IP アドレスにアクセスできない

Azure Container Instances では、通常の Docker 構成のようなポートマッピングはまだサポートされていません。コンテナーグループの IP アドレスにアクセスできるはずの場合にアクセスできない場合は、ports プロパティを使用してコンテナーグループで公開しているのと同じポートをリッスンするようにコンテナーイメージを構成してください。

ご自分のコンテナーイメージで構成したポートで Azure Container Instances がリッスンできることを確認したい場合は、ポートを公開する aci-helloworld イメージのデプロイをテストします。さらに、このポートでリッスンするように aci-helloworld アプリを実行します。 aci-helloworld はオプションの環境変数 PORT を受け取り、既定のリッスンポート 80 を上書きします。たとえば、ポート 9000 をテストするには、コンテナーグループを作成するときに環境変数を設定します。

ポート 9000 を公開するようにコンテナーグループを設定し、そのポート番号を環境変数の値として渡します。この例は、Bash シェル用に書式設定されています。 PowerShell やコマンドプロンプトなどの別のシェルを使用する場合は、それに応じて変数の代入を調整する必要があります。
```
az container create --resource-group myResourceGroup \
--name mycontainer --image mcr.microsoft.com/azuredocs/aci-helloworld \
--ip-address Public --ports 9000 \
--environment-variables 'PORT'='9000'
```
az container create のコマンド出力でコンテナーグループの IP アドレスを見つけます。 ip の値を探します。
コンテナーが正常にプロビジョニングされた後、ブラウザーでコンテナーアプリケーションの IP アドレスおよびポートに移動します (例: 192.0.2.0:9000)。

Web アプリによって "Welcome to Azure Container Instances! (Azure Container Instances へようこそ!)" というメッセージが表示されます。
コンテナーを使い終えたら、az container delete コマンドを使用して削除します。
```
az container delete --resource-group myResourceGroup --name mycontainer
```

機密コンテナーグループのデプロイ時の問題

カスタム CCE ポリシーの使用中のポリシーエラー

カスタム CCE ポリシーは Azure CLI confcom 拡張機能で生成する必要があります。ポリシーを生成する前に、ARM テンプレートで指定されているすべてのプロパティが有効であり、機密コンピューティングポリシーで表されるようにするプロパティと一致していることを確認します。検証するプロパティには、コンテナーイメージ、環境変数、ボリュームマウント、コンテナーコマンドなどがあります。

ポリシーにハッシュがない

Azure CLI confcom 拡張機能では、ローカルコンピューターでキャッシュされたイメージが使用されます。これは、リモートで使用できるイメージと一致しない可能性があり、ポリシーの検証時にレイヤーの不一致が発生する可能性があります。必ず古いイメージを削除し、最新のコンテナーイメージをローカル環境にプルしてください。最新の SHA があることを確認したら、CCE ポリシーを再生成する必要があります。

プロセスまたはコンテナーが終了コード: 139で終了した

この終了コードは、Ubuntu バージョン 22.04 基本イメージの制限事項が原因となって発生します。この問題を解決するには、別の基本イメージを使用することをお勧めします。

コンテナ終了コード

Azure Container Instances内のコンテナーが終了すると、プロセスが停止した理由を示す終了コードがプラットフォームによって報告されます。 az container show コマンドを使用するか、コンテナー> のAzure ポータルでコンテナーイベントを確認することで、終了コードを表示できます。

次の表では、発生する可能性がある一般的な終了コードについて説明します。

終了コード	Description
0	プロセスが正常に完了しました。エラーは発生しませんでした。
1	一般的なアプリケーションエラーが原因でプロセスが終了しました。詳細については、アプリケーションログを確認してください。
137	プロセスは強制的に終了されました (SIGKILL)。この状態は、通常、コンテナーがそのメモリ制限を超えたときに発生します。コンテナーのメモリ割り当てを増やすことを検討してください。
139	プロセスでセグメント化エラー (SIGSEGV) が発生しました。このエラーは、Ubuntu 22.04 などの基本イメージの制限によって発生する可能性があります。別の基本イメージを使用してみてください。
7147	プラットフォームは、終了信号を送信してコンテナーを正常にシャットダウンします。このコードは、コンテナーイベント内の「コンテナーの終了 (プラットフォームによって開始)」というメッセージに対応します。
7148	プラットフォームはコンテナーを強制的に終了しました。通常、この状態は、最初の終了信号を受信した後、コンテナーがタイムリーに応答しなかったことを意味します。このコードは、コンテナーイベントの「コンテナーの終了 (プラットフォームによって開始)」メッセージにも対応します。

プラットフォーム開始終了 (終了コード 7147 および 7148)

終了コード 7147 および 7148 は、基になるインフラストラクチャから取得されるプラットフォーム出口コードです。これらのコードは必ずしもコンテナーの詳細に直接表示されるとは限りませんが、コンテナーイベントに表示される "コンテナーの終了 (プラットフォームによって開始)" メッセージに対応しています。プラットフォームによって開始される終了の一般的な原因は次のとおりです。

インフラストラクチャのメンテナンス: プラットフォームは、定期的なメンテナンスまたは負荷分散の一環としてコンテナーを再配置しました。
リソースの制約: リソースを再利用するために必要な基になるホスト。
プラットフォームの更新: インフラストラクチャが更新され、コンテナーの再起動が必要になりました。

これらの終了は、クラウド環境で想定されます。アプリケーションの可用性を向上するには、複数のコンテナーグループを、Application Gateway または Traffic Manager のようなイングレスコンポーネントの背後で実行します。

プラットフォームによって開始される終了の詳細については、「Service Fabric を使用してコードパッケージの一般的なエラーを診断する」を参照してください。

次のステップ

コンテナーのデバッグを支援するために、コンテナーのログとイベントを取得する方法を学習します。

フィードバック

このページはお役に立ちましたか?

Last updated on 2026-07-26