Azure Container Instances とは

コンテナーは、クラウド アプリケーションのパッケージ化、デプロイ、管理を行う優れた方法としてしだいに普及しつつあります。 Azure Container Instances には、仮想マシンを管理したり、より高度なサービスを採用したりせずに、Azure で最も高速かつ簡単に Linux または Windows コンテナーを実行する方法が用意されています。

ACI では、標準、機密、スポットの各コンテナーがサポートされます。 ACI は、単一インスタンスとして、または NGroups を介してマルチインスタンスとして使用できます。あるいは、ACI 上の仮想ノードを介して Azure Kubernetes Service (AKS) クラスターにポッドをデプロイすることでオーケストレーション機能を得ることもできます。 起動時間をさらに短縮するために、ACI ではスタンバイ プールがサポートされています。

高速なスタートアップ時間

コンテナーは、スタートアップにおいて、仮想マシン (VM) よりもはるかに優れています。 Azure Container Instances を使用すると、VM をプロビジョニングして管理する必要なく、数秒で Azure でコンテナーを開始できます。

Docker Hub、プライベート Azure コンテナー レジストリ、または別のクラウドベースの Docker レジストリから、Linux または Windows のコンテナー イメージを取り込みます。 ACI でサポートされているレジストリについては、FAQ を参照してください。 Azure Container Instances によって複数の一般的な基本 OS イメージがキャッシュされるため、カスタム アプリケーション イメージのデプロイを高速化するのに役立ちます。

起動時間をさらに短縮するために、ACI ではスタンバイ プールがサポートされています。

コンテナー アクセス

Azure Container Instances を使用すると、IP アドレスと完全修飾ドメイン名 (FQDN) を使用してコンテナー グループをインターネットに直接公開できます。 コンテナー インスタンスを作成するとき、カスタム DNS 名ラベルを指定できるので、customlabel.azureregion.azurecontainer.io でアプリケーションに到達できます。

Azure Container Instances では、アプリケーションの開発とトラブルシューティングを支援するために、対話型シェルを提供することで、実行中のコンテナーでのコマンドの実行もサポートしています。 アクセスは HTTPS 経由で行われ、TLS を使用してクライアント接続がセキュリティで保護されます。

準拠しているデプロイ

ハイパーバイザーレベルのセキュリティ

従来のコンテナーでは、アプリケーションの依存関係の分離とリソース ガバナンスは提供されましたが、悪意のあるマルチテナント使用に対するセキュリティの強化は不十分でした。 Azure Container Instances を使用すると、アプリケーションは、VM 内であるかのように、コンテナー内で確実に分離されます。

顧客データ

Azure Container Instances サービスでは、顧客データは格納されません。 ただし、リソースを作成するために使用される Azure サブスクリプションのサブスクリプション ID は格納されます。 コンテナー グループが引き続き想定どおりに実行されるようにするには、サブスクリプション ID の格納が必要です。

カスタム サイズ

コンテナーは、通常、1 つのアプリケーションだけを実行するために最適化されますが、そのようなアプリケーションの正確なニーズはさまざまに異なることがあります。 Azure Container Instances で、CPU のコア数とメモリを厳密に指定することによって最適な稼働率を確保することが可能です。 支払額は、その要求内容に基づいて秒単位で課金されるので、実際のニーズに応じて支出をきめ細やかに調整することができます。

機械学習などの計算集中型ジョブの場合、Azure Container Instances では、NVIDIA Tesla GPU リソース (プレビュー) を使用するように Linux コンテナーをスケジュールできます。

永続的ストレージ

Azure Container Instances を使用して状態を取得および保持できるように、Azure Storage によってサポートされる Azure Files 共有の直接マウントが提供されます。

Linux コンテナーと Windows コンテナー

Azure Container Instances では、同じ API で、Windows と Linux の両方のコンテナーをスケジュールできます。 コンテナー グループを作成するときに、OS の種類の基本設定を指定できます。

一部の機能は、現在のところ Linux コンテナーに限定されています。

• コンテナー グループあたりの複数のコンテナー
• ボリューム マウント (Azure Files、emptyDir、GitRepo、シークレット)
• リソース使用量メトリックと Azure Monitor
• GPU リソース (プレビュー)

Windows コンテナーのデプロイでは、一般的な Windows ベースのイメージに基づくイメージを使用します。

1 つのコンテナー グループで複数のコンテナーを実行する

Azure Container Instances では、同じコンテナー ホスト、ローカル ネットワーク、ストレージ、ライフサイクルを共有する、1 つのコンテナー グループ内の複数コンテナーのスケジュール設定がサポートされています。 これにより、メイン アプリケーション コンテナーを、サイドカーのように主要な機能と併走しながら補助的な役割をつかさどるコンテナー (ログ記録など) と結合することができます。

仮想ネットワークのデプロイ

Azure Container Instances を使用すると、Azure 仮想ネットワークにコンテナー インスタンスをデプロイすることができます。 仮想ネットワーク内のサブネットにデプロイするとき、コンテナー インスタンスでは、オンプレミス上にあるものなど (VPN Gateway または ExpressRoute 経由で)、仮想ネットワークに存在する他のリソースと安全に通信することができます。

可用性ゾーンのサポート

Azure Container Instances では、ゾーン ベースのコンテナー グループのデプロイをサポートしています。したがって、インスタンスは、自分で選んだ特定の可用性ゾーンに固定されます。 可用性ゾーンは、コンテナー グループごとに指定できます。

マネージド ID

Azure Container Instances では、コンテナー グループでのマネージド ID の使用がサポートされているため、資格情報をコンテナー コード内で管理しなくても、Microsoft Entra 認証をサポートする任意のサービスに対してコンテナー グループを認証することができます。

マネージド ID 認証イメージのプル

Azure Container Instances は、マネージド ID を使用して Azure Container Registry (ACR) インスタンスで認証できます。これによりユーザー名とパスワードをコンテナー グループ定義に直接含めなくても、イメージをプルできます。

機密コンテナーのデプロイ

ACI 上の機密コンテナーを使うと、コンテナー ワークロードにハードウェアベースの機密性と整合性保護を提供する高信頼実行環境 (TEE) でコンテナーを実行できます。 ACI 上の機密コンテナーでは、使用中のデータを保護し、メモリ内で処理されるデータを暗号化できます。 ACI 上の機密コンテナーは、ワークロードのデプロイ時に選択できる SKU としてサポートされます。 詳しくは、機密コンテナー グループに関する記事をご覧ください。

スポット コンテナーのデプロイ

ACI スポット コンテナーを使うと、お客様は、未使用の Azure 容量で、割り込み可能なコンテナー化されたワークロードを、通常の優先度の ACI コンテナーと比べて最大 70% の割引価格で実行できます。 ACI スポット コンテナーは、Azure で余剰容量の不足が発生したときに割り込まれる可能性があり、厳密な可用性の要件のないワークロードに適しています。 お客様は、1 秒あたりのメモリとコア使用量に基づいて課金されます。 ACI スポット コンテナーを利用するには、スポット コンテナー グループを使用し、割引価格モデルを利用することを示す特定のプロパティ フラグを使用してワークロードをデプロイできます。 詳細については、スポット コンテナー グループに関するページを参照してください。

NGroups

NGroups には、関連する複数のコンテナー グループを管理するための高度な機能が用意されています。 NGroups では、指定された数のコンテナー グループの維持、ローリング アップグレードの実行、複数の可用性ゾーンにわたるデプロイ、イングレスでのロード バランサーの使用、機密コンテナーのデプロイがサポートされます。 詳細については、NGroups についてのページを参照してください。

Azure Container Instances 上の仮想ノード

Azure Container Instances 上の仮想ノードを使用すると、ACI 内のコンテナー グループとして実行されるポッドを Azure Kubernetes Service (AKS) クラスターにデプロイできます。 これにより、使い慣れた Kubernetes コンストラクトを使用してコンテナー グループを調整できます。 仮想ノードは ACI のサーバーレス インフラストラクチャをベースとしているため、Kubernetes クラスター オートスケーラーが VM コンピューティング ノードをデプロイするのを待つ必要なく、ワークロードをすばやくスケールアップできます。

考慮事項

コマンド ライン インターフェイス (CLI) を介して渡されたユーザーの資格情報は、バックエンドにプレーンテキストとして格納されます。 資格情報をプレーンテキストで格納することはセキュリティ上のリスクです。Microsoft は、ユーザー資格情報をを CLI 環境変数に格納し、バックエンドへの格納時に暗号化および変換されるようにすることをお勧めします。

コンテナー グループが機能しなくなった場合は、サポート リクエストを開く前に、コンテナーを再起動し、アプリケーション コードまたはローカル ネットワーク構成を確認することをお勧めします。

コンテナー イメージを 15 GB より大きくすることはできません。このサイズを超えるイメージは、予期しない動作を引き起こす可能性があります: コンテナー イメージのサイズはどのくらいになる可能性がありますか?

一部の Windows Server 基本イメージは、Azure Container Instances との互換性がなくなりました。
どの Windows ベース OS イメージがサポートされていますか。

コンテナー グループが再起動されると、コンテナー グループの IP が変更される可能性があります。 実際のシナリオでは、ハードコーディングされた IP アドレスを使用することをお勧めします。 静的パブリック IP アドレスが必要な場合は、Application Gateway を使用します: コンテナー グループの静的 IP アドレス - Azure Container Instances | Microsoft Learn

サービス機能用に予約されているポートがあります。 これらのポートを使うと予期しない動作につながるため、使わないことをお勧めします: ACI サービスはサービス機能用にポートを予約しますか?

コンテナーのデプロイまたは実行に問題がある場合は、まず トラブルシューティング ガイドで一般的な間違いや問題を確認してください

プラットフォームのメンテナンス イベントが原因でコンテナー グループが再起動する場合があります。 これらのメンテナンス イベントは、基盤となるインフラストラクチャの継続的な改善を確実にするために行われます: 明示的なユーザー入力なしでコンテナーで分離再起動が行われた

ACI では 特権コンテナー操作は許可されていません。 シナリオにルート ディレクトリを使用しないことをお勧めします。

次のステップ

クイックスタート ガイドを使用して、1 つのコマンドでコンテナーを Azure にデプロイしてみてください。