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

この記事では、Azure Container Instances についてよく寄せられる質問に回答します。

デプロイ

コンテナー イメージのサイズはどのくらいになる可能性がありますか。

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

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

コンテナーのデプロイを高速にするにはどうすればよいですか。

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

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

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

どの Windows ベース OS イメージがサポートされていますか。

Note

2020 年の Windows 更新プログラム以降の下位互換性の問題により、次のイメージ バージョンには、ベース イメージでの使用が推奨されている最小バージョン番号が含まれています。 以前のバージョンのイメージを使用した現在のデプロイは影響を受けませんが、新しいデプロイは次のベース イメージに従う必要があります。 2021 年 6 月 14 日以降、ACI は古いバージョン番号を使用したデプロイをサポートしなくなります。

注意

Azure Container Instances 上の機密コンテナーは、現在、Windows コンテナーをサポートしていません。

Windows Server 2016 ベース イメージ

重要

2022 年 12 月 31 日までは、引き続き Azure Container Instances に Windows Server 2016 コンテナー グループをデプロイできます。 この日付を過ぎると、Windows Server 2016 のイメージはサポートされなくなります。 ワークロードを移行する方法については、「Windows Server 2016 のコンテナー グループを Windows Server 2019 のイメージに移行する方法」をご覧ください。

Note

Semi-Annual Channel 1709 または 1803 に基づく Windows イメージはサポートされていません。

Windows Server 2019 とクライアント ベース イメージ

どの .NET または .NET Core イメージ レイヤーをコンテナーに使用すればよいですか。

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

Note

ACI は、OCI に準拠していないレジストリからイメージをプルすることはできません。

ACI と互換性があるのは、どの種類のコンテナー レジストリですか。

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

Windows Server 2016 のコンテナー グループを Windows Server 2019 のイメージに移行する方法

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

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

    プライベート レジストリを使っている場合は、基本イメージを確認するには Dockerfile を調べうr必要があります。これは、"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 コア数とメモリの上限について、デプロイしているリージョンのリソースの可用性も必ず確認します。

Note

コンテナー グループの少量のリソースは、サービスの基になるインフラストラクチャによって使用されます。 コンテナーでは、グループに割り当てられているほとんどのリソースにアクセスできますが、すべてではありません。 このため、グループ内のコンテナーのリソースを要求するときは、小さいリソース バッファーを計画してください。

ACI はどのような基盤インフラストラクチャ上で動作しますか。

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

ACI に数千個のコアをデプロイしたいのですが、クォータを増やすことはできますか。

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

4 コア、16 GB を超える RAM は展開できますか。

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

特定のリージョンで、ACI はいつ使用できるようになりますか。

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

機能とシナリオ

コンテナー グループをスケールするにはどうすればよいですか。

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

カスタム VNet で実行されているインスタンスにはどのような機能を使用できますか。

選択した Azure 仮想ネットワークにコンテナー グループをデプロイし、プライベート IP をコンテナー グループに委任して、Azure リソース全体で VNet 内のトラフィックをルーティングすることができます。 Azure Container Instances でのネットワークのシナリオと制限事項については、「仮想ネットワークのシナリオとリソース」を参照してください。

ACI サービスはサービス機能用にポートを予約しますか?

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

コンテナー グループの IP アドレスに依存することはできますか?

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

価格

測定の実行はいつ開始されますか。

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

コンテナーを停止するときに課金を停止することはできますか。

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

Azure Container Instances 上の機密コンテナー

コンフィデンシャル コンピューティングとはどのようなもので、Azure Container Instances にどのように適用されますか?

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

どのようなときに Azure Container Instances 上の機密コンテナーを使用する必要がありますか?

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

コンフィデンシャル コンピューティング強制ポリシーはどのようにして生成しますか?

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

Azure Container Instances 上の機密コンテナーでサポートされていない機能はありますか?

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

Azure Container Instances 上の機密コンテナーを使用できるリージョンはどこですか?

Azure Container Instances 上の機密コンテナーは、パブリック プレビューの間は一部のリージョンでのみ使用できます。 現在の利用可能なリージョンについては、こちらで公開されています。

Azure Container Instances 上の機密コンテナーに追加コストはありますか?

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

Azure Container Instances 上のスポット コンテナー (プレビュー)

ACI スポット コンテナーとは?

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

ACI スポット コンテナーを使用するべきなのはいつですか?

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

ACI スポット コンテナーでサポートされていない機能はありますか?

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

ACI スポット コンテナーの既定のクォータは何ですか?

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

ACI スポット コンテナーのクォータのリクエストを提出するための操作方法は?

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

ACI スポット コンテナーはどのリージョンで使用できますか?

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

ACI スポット コンテナーの追加コストはありますか?

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

次のステップ