Azure Container Instances の最上位のリソースは、コンテナー グループです。 この記事では、コンテナー グループとは何か、およびそれらによってどのような種類のシナリオが有効になるかを説明します。
コンテナー グループとは
コンテナー グループは、同じホスト コンピューター上にスケジュール設定されるコンテナーのコレクションです。 コンテナー グループ内のコンテナーでは、ライフサイクル、リソース、ローカル ネットワーク、ストレージ ボリュームを共有します。 これは、Kubernetes のポッドと概念的に似ています。
次の図は、複数のコンテナーを含むコンテナー グループの例を示しています。
この例のコンテナー グループは:
- 単一のホスト コンピューター上にスケジュール設定されます。
- DNS 名ラベルが割り当てられます。
- 単一のパブリック IP アドレスを公開し、1 つの公開ポートを持ちます。
- 次の 2 つのコンテナーから構成されます。 片方のコンテナーはポート 80 でリッスンし、他方のポートはポート 5000 でリッスンします。
- ボリューム マウントとして 2 つの Azure ファイル共有が含まれています。各コンテナーは共有のいずれかをローカルにマウントします。
注
現在、複数コンテナー グループでサポートされているのは、Linux コンテナーのみです。 Windows コンテナーの場合、Azure Container Instances では、1 つのコンテナー インスタンスのデプロイのみがサポートされます。 すべての機能を Windows コンテナーに取り組んでいますが、現在のプラットフォームの違いはサービス の概要にあります。
デプロイメント
複数コンテナー グループをデプロイする一般的な方法として、 Resource Manager テンプレート または YAML ファイルを使用する 方法の 2 つがあります。 コンテナー インスタンスをデプロイするときに、他の Azure サービス リソース ( Azure Files 共有など) をデプロイする必要がある場合は、Resource Manager テンプレートをお勧めします。 YAML フォーマットは簡潔であるため、デプロイにコンテナー インスタンスのみが含まれている場合は、YAML ファイルをお勧めします。 設定できるプロパティの詳細については、 Resource Manager テンプレート リファレンスまたは YAML リファレンス ドキュメントを参照 してください。
コンテナー グループの構成を保持するには、Azure CLI コマンド az container export を使用して構成を YAML ファイルにエクスポートします。 エクスポートを使用すると、"コードとしての構成" のバージョン管理にコンテナー グループの構成を格納できます。または、YAML で新しい構成を開発するときに、エクスポートされたファイルを開始点として使用します。
リソースの割り当て
Azure Container Instances は、グループ内のインスタンスのリソース要求を追加することで、CPU、メモリ、および必要に応じて GPU (プレビュー) などの リソース をマルチコンテナー グループに割り当てます。 CPU リソースを例として取ると、2 つのコンテナー インスタンスを持つコンテナー グループを作成し、それぞれが 1 つの CPU を要求する場合、コンテナー グループには 2 つの CPU が割り当てられます。
コンテナー インスタンス別のリソース使用量
グループ内の各コンテナー インスタンスには、そのリソース要求で指定されたリソースが割り当てられます。 ただし、オプションのリソース制限プロパティを構成すると、グループ内のコンテナー インスタンスによって使用される最大 リソース が異なる場合があります。 コンテナー インスタンスのリソース制限は、必須の リソース要求 プロパティ以上である必要があります。
リソースの制限を指定しない場合、コンテナー インスタンスの最大リソース使用量は、そのリソース要求と同じです。
コンテナー インスタンスの制限を指定した場合、インスタンスの最大使用量は、設定した制限を超える可能性があります。 それに対応して、グループ内の他のコンテナー インスタンスによるリソース使用量が減少する可能性があります。 コンテナー インスタンスに対して設定できるリソースの上限は、グループに割り当てられたリソースの合計です。
たとえば、2 つのコンテナー インスタンスがそれぞれ 1 つの CPU を要求しているグループでは、コンテナーの 1 つが、もう一方よりも多くの CPU を必要とするワークロードを実行する場合があります。
このシナリオでは、コンテナー インスタンスのリソース制限を最大 2 CPU に設定できます。 この構成により、コンテナー インスタンスで使用可能な場合は最大 2 つの CPU を使用できます。
注
コンテナー グループのリソースの少量は、サービスの基になるインフラストラクチャによって使用されます。 コンテナーは、グループに割り当てられているリソースのほとんどにアクセスできますが、すべてのリソースにアクセスできるわけではありません。 このため、グループ内のコンテナーのリソースを要求するときは、小さなリソース バッファーを計画します。
最小割り当てと最大割り当て
コンテナー グループには、 少なくとも 1 つの CPU と 1 GB のメモリを割り当てます。 1 つのグループ内の個々のコンテナー インスタンスは、1 つ未満の CPU と 1 GB のメモリでプロビジョニングできます。
コンテナー グループ内の 最大 リソースについては、デプロイ リージョンでの Azure Container Instances の リソースの可用性 に関するページを参照してください。
ネットワーキング
コンテナー グループは、外部に接続する IP アドレス、その IP アドレス上の 1 つ以上のポート、および完全修飾ドメイン名 (FQDN) を持つ DNS ラベルを共有できます。 外部クライアントがグループ内のコンテナーにアクセスできるようにするには、IP アドレスのポートをコンテナーから公開する必要があります。 コンテナー グループの IP アドレスと FQDN は、コンテナー グループが削除されると解放されます。
コンテナー グループ内では、コンテナー インスタンスは、グループの IP アドレスまたはコンテナーから外部に公開されていない場合でも、任意のポートの localhost 経由で相互に到達できます。
必要に応じて、コンテナー グループを Azure 仮想ネットワーク にデプロイして、コンテナーが仮想ネットワーク内の他のリソースと安全に通信できるようにします。
ストレージ
コンテナー グループにマウントする外部ボリュームを指定できます。 サポートされるボリュームは次のとおりです。
これらのボリュームは、グループの個別のコンテナーの特定のパスにマップできます。
一般的なシナリオ
複数コンテナー グループは、1 つの機能タスクを複数のコンテナー イメージに分割する場合に便利です。 これらのイメージには個別のリソース要件があり、異なるチームがそれらを提供できます。
次のような使用例が考えられます。
- Web アプリケーションにサービスを提供するコンテナーとソース管理から最新のコンテンツをプルするコンテナー。
- アプリケーション コンテナーとログ記録コンテナー。 ログ記録コンテナーは、メイン アプリケーションによって出力されるログとメトリックを収集し、長期保存される記憶域に書き込みます。
- アプリケーション コンテナーと監視コンテナー。 監視コンテナーは、要求を定期的にアプリケーションに送信して、アプリケーションが実行中であり、正常に応答していることを確認します。そうでない場合はアラートを発生させます。
- フロントエンド コンテナーとバックエンド コンテナー。 フロントエンドは、データを取得するためにサービスを実行しているバックエンドと共に、Web アプリケーションを提供する可能性があります。
次のステップ
Azure Resource Manager テンプレートを使用して複数コンテナー コンテナー グループをデプロイする方法について説明します。