コンテナ・インスタンスの概要
Oracle Cloud Infrastructure (OCI) Container Instancesは、サーバーを管理することなく、コンテナを迅速かつ簡単に実行できるサーバーレス・コンピュート・サービスです。コンテナ・インスタンスは、コンテナ・ワークロード用に最適化され、仮想マシンと同じ分離を提供するサーバーレス・コンピュートでコンテナを実行します。
コンテナ・イメージおよびいくつかのパラメータを指定する1つ以上のコンテナを使用してコンテナ・インスタンスを作成できます。基礎となるコンピュート・シェイプの指定、リソース割当て、ネットワーキング、および再起動ポリシーや正常な停止などその他の高度なオプションの構成を柔軟に行うことができます。各コンテナの環境変数、起動オプションおよびリソース制限を構成することもできます。
コンテナ・インスタンスでは、基礎となるコンピュート・シェイプによって提供されるすべてのCPUおよびメモリーをコンテナ・インスタンスに割り当てることができます。これにより、リソース制約を実行せずに、コンテナ内で最も要求の厳しいワークロードでも柔軟に実行できます。
コンテナ・インスタンスは、Kubernetesなどのコンテナ・オーケストレーション・プラットフォームを必要としないコンテナ化されたワークロードに適しています。これらのユース・ケースには、API、Webアプリケーション、CI/CDパイプラインでのビルド・ジョブとデプロイメント・ジョブ、クラウド運用のための自動化タスク、データ/メディア処理ジョブ、開発環境またはテスト環境などがあります。インフラストラクチャを管理せずにKubernetesでコンテナ化されたアプリケーションを実行する場合は、Kubernetesエンジンを参照してください。
必要なIAMポリシー
Oracle Cloud Infrastructureを使用するには、管理者からポリシーでセキュリティ・アクセス権が付与されている必要があります。コンソールまたは(SDK、CLIまたはその他のツールを使用した) REST APIのどれを使用しているかにかかわらず、このアクセス権が必要です。権限を持っていない、または認可されていないというメッセージが表示された場合は、持っているアクセス権のタイプと作業しているコンパートメントを管理者に確認してください。
コンテナ・インスタンスを作成する場合、他のいくつかのリソース(イメージ、クラウド・ネットワーク、サブネットなど)が関係します。このようなその他のリソースは、インスタンスと同じコンパートメントにすることも、他のコンパートメントにすることもできます。インスタンスを起動するために必要な各コンパートメントへのアクセス・レベルを持っている必要があります。
管理者の場合: ユーザーがコンテナ・インスタンスを作成できるようにする最も単純なポリシーは、ユーザーがコンテナ・インスタンスを作成できるようにするを参照してください。指定したグループにコンテナ・インスタンスを管理するための一般アクセス権を付与します。コンテナ・インスタンス・リソースがコンテナ・レジストリからイメージをプルできるようにするには、「コンテナ・インスタンスによるコンテナ・レジストリからのイメージのプル」ポリシーの例を参照してください。
APIの使用およびリクエストの署名の詳細は、REST APIのドキュメントおよびセキュリティ資格証明を参照してください。SDKについては、ソフトウェア開発キットとコマンドライン・インタフェースを参照してください。
コンテナ・インスタンスのシェイプ
コンテナ・インスタンスでは、柔軟性のあるシェイプを使用して、インスタンスに割り当てられるOCPU数およびメモリー容量をカスタマイズできます。コンテナを作成する際、OCPU数およびコンテナで実行するワークロードに必要なメモリー容量を選択します。ネットワーク帯域幅とVNICの数は、OCPUの数に比例してスケーリングされます。この柔軟性により、ワークロードに一致するコンテナを構築できるため、パフォーマンスを最適化し、コストを最小限に抑えることができます。
イベントを使用した自動化の作成
イベント・タイプ、ルールおよびアクションを使用して、Oracle Cloud Infrastructureリソースの状態変更に基づいて自動化を作成できます。詳細は、イベントの概要に関する項を参照してください。
次のコンテナ・インスタンス・リソースからイベントが出力されます:
- コンテナ・インスタンスの作成
- コンテナ・インスタンスの再起動
- コンテナ・インスタンスの起動
- コンテナ・インスタンスの停止
- コンテナ・インスタンスの更新
- コンテナ・インスタンス・コンパートメントの変更
- コンテナ・インスタンスの削除
- コンテナを更新
- コンテナ・インスタンスのメンテナンス
リソース識別子
ほとんどのタイプのOracle Cloud Infrastructureリソースには、Oracle Cloud ID (OCID)と呼ばれる、Oracleによって割り当てられた一意の識別子があります。OCIDのフォーマットおよびその他のリソース識別方法の詳細は、リソース識別子を参照してください。
作業リクエスト
作業リクエストは、長時間実行される操作のモニターに役立ちます。Container Instancesは、作業リクエストAPIではなく、サービスAPIでサポートされている作業リクエストを提供するOracle Cloud Infrastructureサービスの1つです。Oracle Cloud Infrastructureでの作業リクエストの使用の詳細は、ユーザー・ガイドの作業リクエストを参照してください。コンテナ・インスタンスの作業リクエストの詳細は、コンテナ・インスタンスの作業リクエストAPIを参照してください。
Oracle Cloud Infrastructureへのアクセス方法
コンソール(ブラウザベースのインタフェース)またはREST APIドキュメントを使用してOracle Cloud Infrastructureにアクセスできます。コンソールおよびAPIに関する手順は、このガイド全体のトピックに記載されています。使用可能なSDKのリストについては、ソフトウェア開発キットとコマンドライン・インタフェースを参照してください。
コンソールにアクセスするには、サポートされているブラウザを使用する必要があります。コンソールのサインイン・ページに移動するには、このページの上部にあるナビゲーション・メニューを開き、「Infrastructureコンソール」をクリックします。クラウド・テナンシ、ユーザー名およびパスワードを入力してください。
APIの使用の詳細は、REST APIのドキュメントを参照してください。
認証と認可
Oracle Cloud Infrastructureの各サービスは、すべてのインタフェース(コンソール、SDKまたはCLI、およびREST API)で、認証および認可のためにIAMと統合されます。
組織の管理者は、グループ、コンパートメントおよびポリシーを設定して、どのユーザーがどのサービスおよびリソースにアクセスできるかと、そのアクセス権のタイプを制御する必要があります。たとえば、ポリシーは、新しいユーザーの作成、クラウド・ネットワークの作成と管理、インスタンスの起動、バケットの作成、オブジェクトのダウンロードなどを実行できるユーザーを制御します。
- 新しい管理者は、ポリシーの開始を参照してください。
- このサービスのポリシー記述の詳細は、コンテナ・インスタンスIAMポリシーを参照してください。
- 他のサービスのポリシー記述の詳細は、ポリシー・リファレンスを参照してください。
- イメージのプルに認可が必要なプライベート・レジストリまたはリポジトリでのコンテナ・イメージのホストの詳細は、イメージ・プル認可のVaultシークレットを参照してください。
管理者以外の通常のユーザーが会社所有のOracle Cloud Infrastructureリソースを使用する必要がある場合は、管理者に連絡してユーザーIDを設定してください。管理者は、ユーザーが使用する1つ以上のコンパートメントを承認できます。
停止したコンテナ・インスタンスのリソース請求
コンテナ・インスタンスの場合、請求は、コンテナ・インスタンスの作成に使用するシェイプによって異なります。コンテナ・インスタンスは、コンテナ・インスタンスが停止したときに請求を一時停止する標準シェイプを使用します。ただし、停止および失敗したインスタンスは引き続きサービス制限数にカウントされます。
コンテナ・インスタンスの状態 |
説明 |
請求 |
---|---|---|
作成中 |
コンテナ・インスタンスを作成しています。 |
いいえ |
アクティブ | コンテナ・インスタンスがアクティブであるか、コンテナ・イメージがプルされているか、コンテナが実行されています。 | はい |
更新しています |
コンテナ・インスタンスの構成を変更します。例:
コンテナ・イメージや自動再起動ポリシーなどの属性は、コンテナ・インスタンスの再起動後に有効になります。 コンテナ・インスタンスは、再起動、起動、停止後に「更新中」状態になります。 コンテナ・インスタンスを停止すると、そのコンテナ・インスタンスの請求が一時停止されます。コンテナ・インスタンスが再度アクティブになると、請求が再開されます。 |
はい |
失敗 | コンテナ・インスタンスは機能しなくなり、リカバリできません。「失敗」状態は永続的です。 たとえば、ユーザー入力が無効なためにコンテナ・インスタンスの作成が失敗した場合、コンテナ・インスタンスは「失敗」状態になります。無効なユーザー入力の例は、ユーザーが存在しないコンテナ・イメージを指定した場合、またはユーザーが十分な認可方法を提供していないためにコンテナ・インスタンス・サービスがコンテナ・イメージをプルできない場合です。 |
いいえ |
非アクティブ |
コンテナ・インスタンスを停止したため、ユーザー入力なしで再度起動することはありません。 または コンテナ・インスタンス内のすべてのコンテナが停止し、自動再起動ポリシーが無効になります。 コンテナ・インスタンス・インフラストラクチャが削除されます。請求が停止されました。 |
いいえ |
削除中 | DeleteContainerInstance APIコールを使用してコンテナ・インスタンスの削除をリクエストすると、コンテナ・インスタンスは「削除中」状態になります。 コンテナ・インスタンス・インフラストラクチャを削除しています。 |
いいえ |
削除されました | コンテナ・インスタンスが削除されます。DeleteContainerInstanceが完了しました。 | いいえ |
コンテナ・インスタンス・リソースの制限
適用可能な制限の一覧および制限の引上げをリクエストする方法については、サービス制限を参照してください。リソースまたはリソース・ファミリにコンパートメント固有の制限を設定するために、管理者は、コンパートメント割当て制限を使用できます。
多くのコンテナ・インスタンス操作はスロットルの対象となります。
サービス制限はホスト容量とは異なります。サービス制限は、リソースに対して設定された割当てまたは許容量です。ホスト容量は、コンテナ・インスタンスなどのリソースが実行される物理インフラストラクチャです。