Azure Container Instances についてよく寄せられる質問

Azure Container Instances のデプロイ可能なコンテナー イメージの最大サイズは 15 GB です。 デプロイ時の可用性そのものによっては、より大きなイメージをデプロイできる場合がありますが、大きいイメージ サイズは保証されていません。

コンテナー イメージのサイズはデプロイにかかる時間に影響するため、一般的にはコンテナー イメージをできるだけ小さくすることをお勧めします。

デプロイ時間の主な決定要因の 1 つはイメージのサイズなので、サイズを小さくする方法を探します。 不要なレイヤーを削除したり、イメージ内のレイヤーのサイズを小さくします (より軽いベース OS イメージを選択します)。 たとえば、Linux コンテナーを実行している場合は、完全な Ubuntu Server ではなく Alpine をベース イメージとして使用することを検討します。 同様に、Windows コンテナーの場合は、可能であれば Nano Server のベース イメージを使用します。

また、List Cached Images API を通して利用できる Azure Container Images の中に事前にキャッシュされたイメージの一覧を確認することも必要です。 事前にキャッシュされたいずれかのイメージのためにイメージ レイヤーを切り替えることができる場合があります。

コンテナーの起動時間の短縮に関する詳細なガイダンスを参照してください。

• Nano Server: sac2016、10.0.14393.3568 以降
• Windows Server Core: ltsc2016、10.0.14393.3568 以降

• Nano Server: 1809、10.0.17763.1040 以降
• Windows Server Core: ltsc2019、1809、10.0.17763.1040 以降
• Windows: 1809、10.0.17763.1040 以降

お客様の要件を満たす最小のイメージを使用します。 Linux の場合は、.NET Core 2.1 のリリース以降のサポートされている runtime-alpine .NET Core イメージを使用できます。 Windows で、完全な .NET Framework を使用している場合は、Windows Server Core イメージ (4.7.2-windowsservercore-ltsc2016 などのランタイム専用イメージ) を使用する必要があります。 ランタイム専用イメージはより小さいですが、.NET SDK を必要とするワークロードをサポートしていません。

ACI では、ACR とその他の Microsoft 以外のコンテナー レジストリ (DockerHub など) からのイメージのプルがサポートされています。 ACI では、ACR とその他の Microsoft 以外の OCI 互換コンテナー レジストリ (DockerHub など) からの、インターネットに公開されているエンドポイントを使用したイメージのプルがサポートされています。

1. 現在使っている Windows の基本イメージを確認します。

   Microsoft Container Registry (MCR) から直接プルしている場合は、そのイメージ名が基本イメージです。

   プライベート レジストリを使っている場合は、基本イメージを確認するには Dockerfile を調べうｒ必要があります。これは、"FROM" 行の後に記述されています。

2. Windows Server 2019 から使用する新しい基本イメージを選びます。 Azure Container Instances 上でよく使用されている Windows Server 2016 のイメージの例と、その後継としてお勧めする Windows Server 2019 のイメージを次に示します。

   Windows Server 2016 のイメージ	推奨される Windows Server 2019 のイメージ
   mcr.microsoft.com/windows/servercore/iis	mcr.microsoft.com/windows/servercore/iis:windowsservercore-ltsc2019
   mcr.microsoft.com/windows/servercore:ltsc2016	mcr.microsoft.com/windows/servercore:ltsc2019

   詳細については、「イメージの検出」を参照してください。

   Note

   新しい基本イメージの選択に関するサポートが必要な場合は、Azure サポート チケットを作成してください。

3. Azure Container Instances のコンテナーの更新に関するハウツー ガイドに従って、新しい基本イメージを使うように ACI コンテナー グループを更新します。

   コンテナー レジストリに MCR を使っている場合は、コンテナー グループ イメージ パラメーターに MCR イメージ名を直接渡すことができます。

   プライベート コンテナー レジストリを使用している場合は、「コンテナーを新しいバージョンの Windows オペレーティング システムにアップグレードする」の手順に従ってください。 コンテナー グループのイメージ レジストリ パラメーターを変更した場合は、それを必ず更新してください。

実際のところ、これはワークロードによって異なります。 小規模から始めてパフォーマンスをテストし、コンテナーの動作を確認します。 CPU およびメモリ リソースの使用状況を監視します。次に、コンテナーにデプロイするプロセスの種類に基づいてコアまたはメモリを追加します。

コンテナー グループごとに使用できる CPU コア数とメモリの上限について、デプロイしているリージョンのリソースの可用性も必ず確認します。

Azure Container Instances は、サーバーレスのコンテナー オンデマンド サービスであることを目的としているため、コンテナーの開発に集中してください。インフラストラクチャについて心配する必要はありません。 パフォーマンスの比較に関心がある場合、または比較する場合、ACI は主に F シリーズと D シリーズのさまざまな SKU の Azure VM セット上で動作します。 サービスの開発と最適化に伴い、今後これは変わると予想されます。

はい (場合によります)。 現在のクォータと、要求によって上げることができる上限については、クォータと制限に関する記事を参照してください。

まだありません。 現時点では、これらがコンテナー グループ 1 つあたりの最大値です。 具体的な要件や要求については Azure サポートにお問い合わせください。

現在の利用可能なリージョンについては、こちらで公開されています。 特定のリージョンの要件がある場合は、Azure サポートにお問い合わせください。

現在、スケーリングはコンテナーまたはコンテナー グループには使用できません。 より多くのインスタンスを実行する必要がある場合は、API を使用して、サービスへのコンテナー グループ作成のより多くの要求を自動化および作成します。

コンテナー グループを任意の Azure 仮想ネットワークの中に展開し、プライベート IP をそのコンテナー グループに委任することによって、その仮想ネットワーク内ですべての Azure リソースにわたってトラフィックをルーティングすることができます。 Azure Container Instances でのネットワークのシナリオと制限事項については、「仮想ネットワークのシナリオとリソース」を参照してください。

はい。ACI サービスは、サービス機能用に次のポートを予約します: 22、1025-1027、3389-3399、9999、19000、19080、19390、19100、20000-30000、49152-65534。 これらのポートは、コンテナー グループ定義では使用しないでください。

コンテナー グループの IP アドレスは、作成または削除された後に変更される可能性があります。 アプリケーション コードが、コンテナー グループの IP アドレスに依存しないようにすることをお勧めします。 また、静的 IP アドレスを維持する場合は、NAT Gateway または Application Gateway を使用することをお勧めします。

コンテナー グループの期間は、最初のコンテナーのイメージのプルを開始した時点 (新しいデプロイの場合)、またはコンテナー グループが再開された時点 (既にデプロイされている場合) から、コンテナー グループが停止するまでの時間です。 詳細については、「Container Instances の価格」を参照してください。

コンテナー グループ全体が停止すると、測定は停止します。 コンテナー グループのコンテナーが実行されている限り、コンテナーを再起動する場合に備えてリソースは保持されます。

コンフィデンシャル コンピューティングは、コンフィデンシャル コンピューティングを定義し、その導入を促進することに特化した団体である Confidential Computing Consortium (CCC) によって定義された業界用語です。 CCC では、コンフィデンシャル コンピューティングを次のように定義しています。ハードウェアベースの信頼できる実行環境 (TEE) で計算を実行することによる、使用中のデータの保護。 ACI 機密コンテナーでは、ハードウェアベースの保護、コードの整合性、高信頼実行環境 (TEE) の検証が導入されています。 機密コンテナーにより、最新のコンフィデンシャル コンピューティング ハードウェアが適用され、お客様はハードウェアベースのデータ保護を利用しながら、変更なしで既存のアプリケーションをデプロイできます。 コードの整合性と TEE の検証は、デプロイ時にコンテナー グループにアタッチされるコンフィデンシャル コンピューティング適用ポリシーの構成証明によって実現されます。 コンテナー グループのプロパティのいずれかが機密コンピューティング適用ポリシーのものと異なる場合は、環境の起動が失敗するため、TEE が侵害されることはありません。

機密コンテナーは、広範なエラスティック ワークロードに使用できますが、特に適しているのは強力なデータ保護の保証を必要とするワークロードです。 このようなワークロードの例としては、個人データを含むデータ セットを利用する機械学習ワークロードや、知的財産と見なされるアルゴリズムを含むものなどです。 医療関係のお客様は、患者データの分析や調査にそれを使用できます。 金融サービスのお客様は、信用分析リスクの計算やポートフォリオの均衡に使用できます。

コンフィデンシャル コンピューティング適用ポリシーは、confcom 拡張機能と Azure CLI を使って生成できます。 詳しくは、confcom 拡張機能に関するページを参照してください。

GPU ベースの ACI コンテナーのデプロイと Windows コンテナーは、機密コンテナーではサポートされていません。

機密コンテナーの現在の利用可能なリージョンは、こちらで公開されています。

Azure Container Instances 上の機密コンテナーには、Standard SKU コンテナー グループと比較して追加のコストがかかります。 詳しくは、価格のページをご覧ください。

ACI スポット コンテナーは、未使用の Azure 容量で割り込み可能なコンテナー化されたワークロードを、通常の優先度の ACI コンテナーと比較して最大 70% 割引された価格で実行できる新機能です。

ACI スポット コンテナーは、Azure の余剰容量が不十分な場合に割り込まれる可能性があり、1 秒あたりのメモリ/コア使用量に対して課金されます。 ACI スポット コンテナーによって、バッチ処理、モンテカルロ シミュレーション、開発/テスト ワークロード、割り込みを許容できる並列化可能なオフライン ワークロードなどのコンテナー化されたワークロードを Azure 上で従来の ACI 価格のコストの数分の一で実行できるようになりました。 このオファリングは、厳密な可用性要件はなしで割り込み可能なワークロードを実行したいお客様を対象としています。

GPU ベースの ACI コンテナーのデプロイ、可用性ゾーン、パブリック IP を使用した ACI デプロイ及びプライベート IP を使用したカスタム仮想ネットワーク背後での ACI デプロイのサポートは、スポット コンテナーではサポートされていません。

すべてのお客様は、既定のクォータである 10 個の vCPU コアと 10 個のコンテナー グループを取得します。

お客様は、必要な詳細を入力するように要求されたときに、問題の種類を "サービスとサブスクリプションの制限 (クォータ)"、新しいクォータの種類を ACI スポット コンテナー オファリングに追加された "StandardSpotCores" として選択することで、スポット コンテナーの容量を増やすためのサポート リクエストを提出できます。

Azure Container Instances (ACI) スポット コンテナーは、パブリック プレビューの間は一部のリージョンでのみ利用できます。 詳細については、「リソースとリージョンの利用可能性」を参照してください。

ACI スポット コンテナーは割引価格で提供されており、通常の優先度の ACI コンテナーと比較して最大 70% の割引が提供されます。 割引は、各リージョンで月ごとに異なります。 詳細については、 価格に関するページを参照してください。

次のステップ

• Azure Container Service の詳細情報。
• Azure Container Instances の一般的な問題のトラブルシューティング。