コンパートメント内のリソースの編成

コンパートメントの理解

コンパートメントを使用してクラウド・リソースを編成および分離する方法について慎重に検討してください。コンパートメントは、そのプロセスに不可欠です。ほとんどのリソースはコンパートメント間で移動できます。ただし、何も実装する前に、組織のコンパートメント設計を事前に検討することが重要です。

コンパートメント構造を計画する際は、次の点に注意してください:

テナンシまたはルート・コンパートメントの下に、最大6個のコンパートメントの階層を作成できます。
コンパートメントは、物理的ではなく論理的です。関連リソース・コンポーネントは異なるコンパートメントに配置できます。たとえば、インターネット・ゲートウェイにアクセスできるクラウド・ネットワーク・サブネットは、同じクラウド・ネットワーク内の他のサブネットとは別のコンパートメントに保護できます。
コンパートメントは、リソースを表示するためのフィルタのように動作します。コンパートメントを選択すると、「コンピュートWeb UI」にはそのコンパートメントにあるリソースのみが表示されます。別のコンパートメントのリソースを表示するには、まずそのコンパートメントを選択する必要があります。

このエクスペリエンスは、ユーザー、グループおよびフェデレーション・プロバイダを表示する場合に異なります。これらは、個々のコンパートメントではなくテナンシ自体に存在します。ポリシーは、テナンシまたはコンパートメントにアタッチできます。アタッチされている場所によって、だれがそれを変更または削除できるかが制御されます。
「コンピュートWeb UI」には、アクセス権があるコンパートメントおよびリソースのみが表示されます。すべてのコンパートメントを表示し、すべてのリソースを操作できるのは管理者のみです。
リソース(たとえば、ブロック・ストレージ・ボリューム、VCN、サブネット)の作成時に、配置するコンパートメントを決定する必要があります。

リソース・アクセスの付与に関する考慮事項

テナンシの設定を計画する際のもう1つの主な考慮事項は、誰がどのリソースにアクセスする必要があるかです。様々なユーザー・グループがリソースにアクセスする必要がある方法を定義すると、リソースを最も効率的に編成する方法を計画できるため、アクセス・ポリシーの記述と保守が容易になります。

たとえば、次のことを必要とするユーザーがあるとします:

「コンピュートWeb UI」を表示しますが、リソースの編集または作成は許可されません
複数のコンパートメントにわたる特定のリソースを作成および更新します。たとえば: クラウド・ネットワークおよびサブネットを管理する必要があるネットワーク管理者
インスタンスとブロック・ボリュームを起動および管理しますが、クラウド・ネットワークにはアクセスできません
すべてのリソースに対する完全な権限を持ちますが、特定のコンパートメント内のみです
他のユーザーの権限および資格証明を管理

複数のテナンシのリソースへのアクセスの詳細は、「クロステナンシ・ポリシー」を参照してください。

コンパートメント組織の例

この項では、リソース管理の目標に合せてコンパートメントを構成する方法について説明します。

ルート・コンパートメント内のすべてのリソース

組織が小規模な場合、または概念実証段階にいる場合は、すべてのリソースをルート・コンパートメントまたはテナンシに配置することを検討してください。この方法を使用すると、すべてのリソースをすばやく表示および管理できます。ポリシーを記述し、グループを作成して、特定のリソースに対する権限を、アクセスを必要とするユーザーのみに制限することもできます。

単一コンパートメント・アプローチを設定する高度なタスク:

サンドボックス・コンパートメントを作成します。ルート・コンパートメントにリソースを保持する計画ですが、Oracleでは、機能を試す専用の領域をユーザーに提供できるように、サンドボックス・コンパートメントを設定することをお薦めします。サンドボックス・コンパートメントでは、テナンシ(ルート)コンパートメント内のリソースに対するより厳しい権限を維持しながら、リソースの作成および管理権限をユーザーに付与できます。
グループおよびポリシーの作成。
ユーザーを追加します。

個別管理プロジェクト・コンパートメント

組織に複数の部門があり、個別に管理したい場合や、個別に管理しやすくなる異なるプロジェクトが複数存在する場合には、このアプローチを検討してください。

このアプローチでは、そのプロジェクトのみのアクセス・ポリシーを設定できる各プロジェクト・コンパートメントに専用管理者グループを追加できます。ユーザーおよびグループは引き続きテナンシ・レベルで追加する必要があります。 1つのグループにすべてのリソースに対する制御を付与できますが、ルート・コンパートメントまたは他のプロジェクトに対する管理者権限は許可しません。このようにして、様々なグループが独自のリソースに対して独自の「サブ・クラウド」を設定し、個別に管理できるようにします。

マルチ・プロジェクト・アプローチを設定するためのハイ・レベル・タスク:

サンドボックス・コンパートメントを作成します。 Oracleでは、機能を試す専用のスペースをユーザーに付与できるように、サンドボックス・コンパートメントを設定することをお薦めします。サンドボックス・コンパートメントでは、テナンシおよび他のコンパートメントのリソースに対するより厳しい権限を維持しながら、リソースを作成および管理する権限をユーザーに付与できます。
各プロジェクトのコンパートメントを作成します。たとえば: ProjectA, ProjectB.
プロジェクトごとに管理者グループを作成します。たとえば: ProjectA_Admins.

各管理者グループのポリシーを作成します。たとえば:

Allow group ProjectA_Admins to manage all-resources in compartment ProjectA

ユーザーを追加します。
ProjectAおよびProjectBの管理者が指定のコンパートメント内に、リソースを管理するためのサブコンパートメントを作成できるようにします。
ProjectAおよびProjectBの管理者に、コンパートメントへのアクセスを管理するポリシーを作成します。

コンパートメントの操作

この項では、コンパートメント管理の基本について説明します。

コンパートメントの作成

コンパートメントを作成する場合、テナンシ内で一意の名前を指定する必要があります。最大100文字の長さで、文字、数字、ピリオド、ハイフンおよびアンダースコアを含めることができます。コンパートメントの説明も指定する必要があります。この説明の長さは1から400文字で、一意で変更も可能です。新しいコンパートメントには、OracleクラウドID (OCID)と呼ばれる一意の識別子が自動的に割り当てられます。

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

コンパートメント・アクセス制御

コンパートメントの作成後、少なくとも1つのポリシーを記述する必要があります。そうしないと、テナンシ・レベルで設定された権限を持つ管理者およびユーザーにのみアクセスできます。別のコンパートメント内にコンパートメントを作成すると、サブコンパートメントはその階層の上位にあるコンパートメントからアクセス権限を継承します。

アクセス・ポリシーを作成する場合は、それをアタッチするコンパートメントを指定する必要があります。これは、後でポリシーを変更または削除できるユーザーを制御します。コンパートメント階層設計によっては、テナンシ、親または特定のコンパートメント自体にアタッチできます。

複数のテナンシのリソースへのアクセスの詳細は、「クロステナンシ・ポリシー」を参照してください。

コンパートメントへのリソースの追加

「コンピュートWeb UI」でクラウド・リソースの操作を開始する場合、作業するコンパートメントをリストから選択する必要があります。そのリストは、アクセス権のあるテナンシ内のコンパートメントのみを表示するようにフィルタ処理されます。

新しいリソースをコンパートメントに配置するには、リソースの作成時にそのコンパートメントを指定するだけです。コンパートメントは、リソースを作成するために必要なパラメータの1つです。「コンピュートWeb UI」で作業する場合は、まずリソースを作成するコンパートメントを表示していることを確認します。

ほとんどのIAMリソースはテナンシに存在することに注意してください。これは常にユーザーとグループの場合に該当しますが、コンパートメントとポリシーはテナンシにもアタッチされます。テナンシ・レベルのリソースは、特定のコンパートメントから作成または管理できません。

コンパートメント間でのリソースの移動

ほとんどのリソースは、作成後に移動できます。

一部のリソースには、リソースの依存関係がアタッチされています。親リソースを別のコンパートメントに移動すると、アタッチされている依存関係がすべて同じように動作することはありません。一部のリソースは親リソースとともにすぐに移動され、一部は非同期的に移動されます。つまり、移動が完了するまで新しいコンパートメントには表示されません。他のリソースの場合、アタッチされたリソースの依存性は、新しいコンパートメントに自動的に移動されません。これらのアタッチされたリソースは個別に移動できます。

リソースを新しいコンパートメントに移動すると、新しいコンパートメントを制御するポリシーがただちに適用され、リソースへのアクセスに影響します。各リソースとそのアタッチメントの動作をよく理解するには、個々のリソースのサービス・ドキュメントを参照してください。

コンパートメントの削除

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

削除アクションは非同期で、作業リクエストが開始され、通常は完了までに数分かかります。コンパートメントは「削除」状態ですが、コンパートメント・ピッカーに表示されません。作業リクエストが失敗した場合、コンパートメントは削除されず、active状態に戻ります。操作中の作業リクエストの進捗状況を追跡したり、作業リクエストが正常に完了したか、エラーが発生したかを確認できます。

コンパートメントが削除されると、その状態は「削除済」に更新され、ランダムな文字列がその名前に追加されます。たとえば、CompartmentAはCompartmentA.qR5hP2BDになります。コンパートメントの名前を変更すると、別のコンパートメントの元の名前を再利用できます。削除されたコンパートメントは、コンパートメント・ページに365日間表示されますが、コンパートメント・ピッカーから削除されます。削除されたコンパートメントを参照するポリシー・ステートメントがある場合、これらのステートメントは新しい名前を反映するように更新されます。

作業リクエストでコンパートメントの削除に失敗したことが示されている場合は、すべてのリソースを削除したことを確認します。コンパートメントにポリシーがないことを確認します。コンパートメント内のリソースが見つからない場合は、管理者に確認してください。すべてのリソースを表示する権限がない可能性があります。

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

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

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

コンパートメントを移動する場合、次の制限が適用されます:

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

ポリシーの影響

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

現在の位置にあるコンパートメントへのアクセスを制御するポリシーに注意してください。
コンパートメントを移動したときに有効になる新しい親コンパートメント内のポリシーに注意してください。

現在のコンパートメント内のリソースへのアクセス権を持つグループは、コンパートメントの移動時に権限を失い、宛先コンパートメント内の権限を持つグループはアクセス権を取得します。コンパートメントを移動するときにどのグループが権限を失うかだけでなく、どのグループが権限を取得するかも認識していることを確認します。必要に応じて、特定のユーザーが誤ってアクセスを失わないようにポリシー・ステートメントを調整します。

タグ付けの影響

コンパートメントの移動後にタグが自動的に更新されることはありません。コンパートメントに基づいたタグ付け戦略を実装している場合は、コンパートメントの移動後にリソースのタグを更新する必要があります。

たとえば、CompartmentAにCompartmentBという名前の子コンパートメントがあるとします。 CompartmentAは、CompartmentAのすべてのリソースがTagAでタグ付けされるように、タグのデフォルトで設定されます。したがって、CompartmentBとそのすべてのリソースは、このデフォルト・タグTagAでタグ付けされます。 CompartmentBをCompartmentCに移動しても、CompartmentAのデフォルトのタグのままになります。 CompartmentCのデフォルト・タグを設定している場合は、移動されたコンパートメントのリソースに追加する必要があります。