Oracle Cloud Infrastructureドキュメント

コンパートメントの管理

このトピックでは、コンパートメントでの作業の基本について説明します。

必要なIAMポリシー

管理者グループに所属している場合は、コンパートメントを管理するために必要なアクセス権があります。

コンパートメント管理に関連する追加ポリシーについては、「コンパートメント管理者にコンパートメントを管理させる」を参照してください。

新しいポリシーの場合は、「ポリシーの開始」「共通ポリシー」を参照してください。 コンパートメントやその他のIAMコンポーネントの記述ポリシーを詳しく調べたい場合は、「IAMの詳細」を参照してください。

リソースのタギング

リソースにタグを適用して、ビジネス・ニーズに合わせてタグを整理するのに役立てることができます。 リソースを作成するときにタグを適用することも、後でそのタグを使用してリソースを更新することもできます。 タグの適用に関する一般的な情報は、「リソース・タグ」を参照してください。

コンパートメントの操作

最初にOracle Cloud Infrastructureで作業を開始するときは、コンパートメントを使用してクラウド・リソースを整理して隔離する方法について慎重に検討する必要があります。 コンパートメントはそのプロセスの基本です。 コンパートメント間では多くのリソースを移動できます。 ただし、事前に組織のコンパートメント設計を検討してから、何も実装することが重要です。 詳細は、「あなたのテナンシを設定」を参照してください。

コンソールは、現在のリージョン内のリソースを「コンパートメント」で表示するように設計されています。 コンソールでリソースを操作する際は、ページ上のリストから作業するコンパートメントを選択する必要があります。 このリストは、アクセス権限のあるテナンシ内のコンパートメントのみを表示するようにフィルタされます。 管理者の場合は、すべてのコンパートメントを表示する権限と任意のコンパートメント・リソースを使用する権限がありますが、アクセスが制限されているユーザーの場合はそうではありません。

コンパートメントは、リージョン全体でグローバルです。 コンパートメントを作成すると、テナンシがサブスクライブされているすべてのリージョンで使用可能になります。

コンパートメントの作成

新規コンパートメントを作成する際は、親コンパートメント内で一意である100文字(文字、数字、ピリオド、ハイフン、アンダースコアを含む)のnameを提供する必要があります。 また、1文字から400文字までのコンパートメントの一意でない変更可能な説明であるdescriptionも指定する必要があります。 コンパートメントには、Oracle Cloud IDという一意のIDも割り当てられます。 詳細は、「リソース識別子」を参照してください。

コンパートメント内にサブコンパートメントを作成すると、6レベルの深さの階層を作成できます。

コンパートメント階層の6レベルの深さを示す図

サブ部品をあるコンパートメントから別のコンパートメントに移動することはできません。

コンパートメントの数については、「サービス制限」を参照してください。

コンパートメントのアクセス・コントロール

コンパートメントを作成したら、それに少なくとも1つのポリシーを記述する必要があります。そうしないと、誰もそれにアクセスできません(管理者またはテナンシに対する権限を持つユーザーを除く)。

別のコンパートメント内にコンパートメントを作成する場合、コンパートメントはその階層の上位にあるコンパートメントからアクセス権限を継承します。 詳細は、「ポリシー継承」を参照してください。

アクセス・ポリシーを作成する際、それをアタッチするコンパートメントを指定する必要があります。 これにより、後でポリシーを変更または削除できるユーザーが制御されます。 コンパートメント階層の設計方法に応じて、これをテナンシ、親または特定のコンパートメント自体にアタッチできます。 詳細は、「ポリシー・アタッチメント」を参照してください。

コンパートメント内にリソースを入れる

新しいリソースをコンパートメントに配置するには、リソースを作成するときにコンパートメントを指定するだけです(コンパートメントはリソースを作成するために必要な情報の1つです)。 コンソールで作業している場合は、まずリソースを作成するコンパートメントが表示されていることを確認してください。 ほとんどのIAMリソースはテナンシに存在することに注意してください(これにはユーザー、グループ、コンパートメントおよびテナンシにアタッチされたポリシーが含まれます)。

別のコンパートメントへのリソースの移動

ほとんどのリソースは、作成後に移動できません。 コンパートメント間で移動できるリソースはいくつかあります。 リソースを移動すると、アタッチされたリソース依存性も新規コンパートメントに移動します。 リソースは即時に移動しますが、アタッチされた一部の依存関係は非同期に移動し、移動が完了するまで新規コンパートメントには表示されません。 リソースを新しいコンパートメントに移動すると、固有のポリシーがすぐに適用され、リソースへのアクセスに影響を与えます。 コンパートメント組織の構造に応じて、メータリング、請求およびアラームも影響を受けます。 各リソースのサービス・ドキュメントにアクセスすると、個々のリソース・タイプに固有の効果を確認できます。

コンパートメントのリソースの表示

単一のAPI呼び出しを使用してコンパートメント内のすべてのリソースのリストを取得することはできません。 コンパートメント内の特定のタイプのリソースをすべてリストできます(たとえば、すべてのインスタンス、すべてのブロック・ストレージ・ボリュームなど)。

ヒント

「検索」では、一部の制限付きでコンパートメント内のリソースのリストを取得できます。
「検索」表示しているリージョンにリソースがリストされます。 すべてのリソースが「検索」をサポートするわけではありません。 詳細は、「検索の概要」を参照してください。

コンパートメントの削除

コンパートメントを削除するには、すべてのリソースのうち空である必要があります。 コンパートメントの削除を開始する前に、コンパートメントにアタッチされているポリシーを含め、すべてのリソースが移動、削除または終了していることを確認してください。

重要

一部のリソース・タイプは削除できないため、これらのリソース・タイプを含むコンパートメントは削除できません。 削除できないリソース・タイプは次のとおりです。

  • タグ・ネームスペースおよびタグ・キー定義
  • データ転送ジョブ

削除処理は非同期で、作業リクエストを開始します。 コンパートメントの状態は、作業リクエストの実行中に削除に変わります。 通常、作業リクエストの完了には数分かかります。 削除状態の間、コンパートメント・ピッカーに表示されません。 作業リクエストが失敗すると、コンパートメントは削除されず、アクティブ状態に戻ります。

コンパートメントを削除すると、その状態がDeletedに更新され、ランダムな文字列が名前に追加されます。たとえば、CompartmentAはCompartmentA.qR5hP2BDになります。 コンパートメントの名前を変更すると、別のコンパートメントに元の名前を再利用できます。 削除されたコンパートメントは、「監査保持期間」設定で指定された日数(90-365)のコンパートメント・ページに表示されます。 削除されたコンパートメントはコンパートメント・ピッカーから削除されます。 削除されたコンパートメントを参照するポリシー文がある場合は、ポリシー文の名前が新しい名前に更新されます。

コンパートメントの削除に失敗したときのトラブルシューティング・ヒント
重要

削除されたコンパートメントの「サービス制限」に対するカウントを継続させるため、既知の問題が発生しています。 「コンパートメントが削除され、サービス制限に対するカウントを継続します」も参照してください。

コンパートメントのタグ・デフォルトの追加

タグのデフォルト値を使用すると、現在のコンパートメントで、作成時にすべてのリソースに自動的に適用されるタグを指定できます。 詳細は、「タグのデフォルトの管理」を参照してください。

コンソールの使用

コンパートメントを作成するには
コンパートメント名を更新するには
コンパートメントの説明を更新するには
コンパートメントの内容を表示するには
別のコンパートメントにリソースを移動するには
コンパートメントにタグを適用するには
コンパートメントを削除するには

APIの使用

APIおよび署名リクエストの使用については、REST APIおよび「セキュリティ資格証明」を参照してください。 SDKの詳細は、「ソフトウェア開発キットとコマンドライン・インタフェース」を参照してください。

これらのAPI操作を使用してコンパートメントを管理します:

コンパートメントの内容は、リソース・タイプによってのみ取得できます。 コンパートメント内のallresourcesをリストするAPI呼び出しはありません。 たとえば、コンパートメント内のすべてのインスタンスをリストするには、「コア・サービスAPI」 ListInstancesオペレーションを呼び出し、コンパートメントIDを問合せパラメータとして指定します。