Oracle Cloud Infrastructureドキュメント

コンパートメントの管理

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

必要なIAMポリシー

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

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

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

リソースのタギング

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

コンパートメントの操作

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

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

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

コンパートメントの作成

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

コンパートメントにサブ部品を作成して、6レベル深い階層を作成できます。

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

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

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

コンパートメントを作成した後には、少なくとも1つのポリシーを記述する必要があります。作成しないと、誰もアクセスできません(テナンシ・レベルで権限が設定されている管理者またはユーザーを除く)。 別のコンパートメント内にコンパートメントを作成する場合、コンパートメントはその階層の上位にあるコンパートメントからアクセス権限を継承します。 詳細は、「ポリシー継承」を参照してください。

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

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

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

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

ほとんどのリソースは、作成後に移動できます。 コンパートメント間で移動できないリソースがいくつかあります。

リソースによっては、アタッチされたリソース依存性がありますが、アタッチされていないものもあります。 親リソースを移動した場合、アタッチされているすべての依存性が同じように動作するわけではありません。

一部のリソースでは、アタッチされた依存性は親リソースとともに新しいコンパートメントに移動します。 親リソースは即時に移動しますが、場合によっては、アタッチされた依存関係が非同期に移動し、移動が完了するまで新規コンパートメントには表示されません。

他のリソースの場合、アタッチされたリソース依存関係は新しいコンパートメントに移動しません。 これらのアタッチされたリソースは、個別に移動できます。

リソースを新規コンパートメントに移動した後、新規コンパートメントを管理するポリシーは即時に適用され、リソースへのアクセスに影響します。 コンパートメント組織の構造に応じて、メータリング、請求およびアラームも影響を受けます。

各リソースおよびそのアタッチメントの動作を理解するには、個々のリソースのサービス・ドキュメントを参照してください。

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

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

ヒント

コンソールでは、「検索」により、いくつかの制限を受けてコンパートメント内のリソースのリストを取得できます。
「検索」は、現在選択されているリージョンの結果のみ戻すことができます。 すべてのリソースで「検索」がサポートされるわけではありません。 詳細は、「検索の概要」を参照してください。

コンパートメントの削除

ノート

削除されたコンパートメントは、Oracle Cloud Infrastructure Government Cloudでは使用できません。

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

重要

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

  • データ転送ジョブ

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

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

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

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

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

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

コンパートメントの別の親コンパートメントへの移動

コンパートメントは、同じテナンシ内の別の親コンパートメントに移動できます。 コンパートメントを移動すると、そのすべてのコンテンツ(サブ・パートおよびリソース)も一緒に移動されます。 コンパートメントを移動すると、そのコンテンツに影響を及ぼします。 これらの影響については、以降の項で説明します。 コンパートメントを移動する前に、これらを認識していることを確認してください。

必要なIAMポリシー

コンパートメントを移動するには、現在のコンパートメントおよび宛先コンパートメントの最小共有親コンパートメントに対するmanage all-resources権限を持つグループに属している必要があります。

コンパートメントの移動の制限

  • 移動されているコンパートメントと同じ名前の宛先コンパートメントにコンパートメントを移動することはできません。

    たとえば、コンパートメントAとコンパートメントBがどちらもルート・コンパートメントの下にあるとします。 コンパートメントAの下には、コンパートメントBとも呼ばれるサブ部品があります。 コンパートメントBを親コンパートメントBに移動できません。

    コンパートメントBは、コンパートメントBという名前の親コンパートメントにも移動できません

  • 同じ親に2つのコンパートメントを同じ名前にすることはできません。 そのため、同じ名前のコンパートメントがすでに存在する宛先コンパートメントにコンパートメントを移動することはできません。

コンパートメントの移動時のポリシーの意味の理解

コンパートメントを新規の親コンパートメントに移動した後、新規の親のアクセス・ポリシーは有効になり、前の親のポリシーは適用されなくなります。 コンパートメントを移動する前に、次のことを確認してください:

  • 現在の位置にあるコンパートメントへのアクセスを管理するポリシーを認識しています。
  • コンパートメントを移動すると有効になる新規親コンパートメントのポリシーを認識しています。

階層を指定するポリシーを含むネストされたコンパートメントを移動するときに、ポリシーが自動的に更新されて一貫性が維持される場合があります。

ポリシーの例

現在のコンパートメントの消失アクセス権を持つグループ、宛先コンパートメントの権限を持つグループ増加アクセス

次の図は、A:bの子が階層a :Dに移動したコンパートメントcのコンパートメント階層を示しています。

コンパートメントCは、a:bからa :Dに移動されます。

テナンシには、コンパートメントBとDに次のポリシーが定義されています:

Policy1: Allow group G1 to manage instance-family in compartment A:B

Policy2:  Allow group G2 to manage instance-family in compartment A:D

コンパートメントCがbからdに移動された場合の影響:

グループG1では、コンパートメントc内のインスタンス・ファミリを管理できなくなりました。

グループG2では、コンパートメントcのインスタンス・ファミリを管理できるようになりました。

コンパートメントを移動すると権限が失われるグループだけでなく、どのグループが権限を取得するかを確認してください。

ポリシーの自動更新

コンパートメントを移動すると、一部のポリシーが自動的に更新されます。 移動中のコンパートメントまでのコンパートメント階層を指定するポリシーは、現在およびターゲットの親の共有祖先にポリシーがアタッチされている場合に自動的に更新されます。 次の例を参考にしてください。

例1: ポリシーが自動的に更新されました

ポリシーが共有の祖先にアタッチされると、ポリシーは自動的に更新されます

この例では、Operations:TestからOperations:DevにコンパートメントAを移動します。 コンパートメントAを管理するポリシーは、共有の親である操作にアタッチされます。 コンパートメントを移動すると、新規コンパートメントのロケーションを指定するために、IAMサービスによってポリシー文が自動的に更新されます。

ポリシー

Allow group G1 to manage buckets in compartment Test:A 

更新されました

Allow group G1 to manage buckets in compartment Dev:A

グループG1がそのロケーションのコンパートメントaに引き続きアクセスできるようにするには、手動の介入は必要ありません。

例2: ポリシーは更新されていません

ポリシーは更新されていません

この例では、Operations:TestからOperations:DevにコンパートメントAを移動します。 ただし、ここでコンパートメントAを管理するポリシーは、テスト・コンパートメントに直接アタッチされています。 コンパートメントが移動されても、ポリシーは自動的に更新されません。 コンパートメントAを指定するポリシーは有効ではなく、手動で削除する必要があります。 グループG1は、Devの新しいロケーションにあるコンパートメントAにアクセスできなくなりました。 別の既存のポリシーでグループG1へのアクセス権が付与されていないかぎり、コンパートメントaのバケットの管理をG1で続行できるようにするための新しいポリシーを作成する必要があります。

例3: テナンシにアタッチされたポリシーが更新されます

ポリシーが共有の祖先にアタッチされると、ポリシーは自動的に更新されます

この例では、操作:テストからHR :Pオフラインにコンパートメントaを移動します。 コンパートメントAを管理するポリシーは、元の親コンパートメントと新しい親コンパートメントによって共有祖先であるテナンシにアタッチされます。 したがって、コンパートメントを移動すると、新規コンパートメントのロケーションを指定するために、IAMサービスによってポリシー文が自動的に更新されます。

ポリシー文:

Allow group G1 to manage buckets in compartment Operations:Test:A 

更新されました

Allow group G1 to manage buckets in compartment HR:Prod:A

グループG1がコンパートメントaへのアクセスを続行できるようにするには、手動の介入は必要ありません。

コンパートメントの移動時のコンパートメント割当の暗黙の理解

コンパートメントを他のコンパートメントに移動すると、宛先コンパートメントのリソース割当て制限は検証されず、強制されません。 したがって、コンパートメントの移動によって宛先コンパートメントの割当て容量違反が発生した場合、その移動はブロックされません。 移動が完了すると、宛先コンパートメントは、割当て容量超過状態になります。 宛先コンパートメントの割当て制限を調整するか、既存の割当て容量に準拠するためにリソースを削除するまで、割当て容量を超過している新しいリソースを作成できません。 コンパートメントの割当て制限の管理の詳細は、『「コンパートメント割当」』を参照してください。

コンパートメントの移動時のタグ付けの意味の理解

コンパートメントの移動後、タグは自動的に更新されません。 コンパートメントに基づくタグ付け戦略を実装している場合は、移動後にリソースのタグを更新する必要があります。 たとえば、CompartmentAにCompartmentBという子コンパートメントがあるとします。 CompartmentAでは、タグ・デフォルトを使用して設定され、CompartmentA内のすべてのリソースにTagAのタグが付けられます。 したがって、CompartmentBとそのすべてのリソースは、デフォルト・タグTagAでタグ付けされます。 CompartmentBをCompartmentCに移動しても、デフォルトのタグはCompartmentAにあります。 CompartmentCのデフォルト・タグを設定した場合、それらを移動したコンパートメントのリソースに追加する必要があります。

コンパートメントを移動した後は、タグのデフォルト値は更新されません

コンソールの使用

警告

Oracle Cloud Infrastructureコンソール、APIまたはCLIを使用してクラウド・リソースに説明、タグまたはわかりやすい名前を割り当てるときは、機密情報を入力しないでください。

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

APIの使用

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

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

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