Mit Compartments arbeiten

Erfahren Sie, wie Sie Ihre Cloud-Ressourcen in OCI mit Compartments organisieren.

Bevor Sie mit Oracle Cloud Infrastructure arbeiten, müssen Sie sich sorgfältig überlegen, wie Sie Ihre Cloud-Ressourcen mit Compartments organisieren und isolieren möchten. Compartments sind für diesen Prozess von wesentlicher Bedeutung. Die meisten Ressourcen können zwischen Compartments verschoben werden. Es ist jedoch wichtig, sich vor der Implementierung mit dem Compartment-Design für Ihre Organisation vertraut zu machen. Weitere Informationen finden Sie unter Best Practices zum Einrichten Ihres Mandanten.

Die Konsole ist so ausgelegt, dass Ihre Ressourcen nach Compartment in der aktuellen Region angezeigt werden. Wenn Sie mit Ihren Ressourcen in der Konsole arbeiten, müssen Sie in einer Liste auf der Seite auswählen, in welchem Compartment Sie arbeiten möchten. Diese Liste wird gefiltert, damit nur die Compartments in dem Mandanten angezeigt werden, für die Sie Zugriffsberechtigungen besitzen. Wenn Sie ein Administrator sind, haben Sie die Berechtigung, alle Compartments anzuzeigen und mit den Ressourcen eines Compartments zu arbeiten. Wenn Sie jedoch ein Benutzer mit eingeschränktem Zugriff sind, sind Sie dazu wahrscheinlich nicht berechtigt.

Compartments gelten für den gesamten Mandanten, und zwar regionsübergreifend. Wenn Sie ein Compartment erstellen, ist es in jeder Region verfügbar, die Ihr Mandant abonniert hat. Mit dem Mandanten-Explorer können Sie eine regionsübergreifende Ansicht Ihrer Ressourcen in einem bestimmten Compartment abrufen. Siehe Alle Ressourcen in einem Compartment anzeigen.

Für zusätzliche Sicherheit können Sie ein Compartment mit einer Sicherheitszone verknüpfen. Weitere Informationen finden Sie unter Sicherheitszonen.

Diese Einführung enthält die folgenden Themen:

Zugriffskontrolle für Compartments

Nachdem Sie ein Compartment erstellt haben, müssen Sie mindestens eine Policy für das Compartment schreiben. Sonst kann niemand darauf zugreifen (außer Administratoren oder Benutzer, für die Berechtigungen auf Mandantenebene festgelegt sind). Wenn Sie ein Compartment in einem anderen Compartment erstellen, erbt das Compartment die Zugriffsberechtigungen von den übergeordneten Compartments in der Hierarchie. Weitere Informationen finden Sie unter Policy-Vererbung.

Wenn Sie eine Zugriffs-Policy erstellen, müssen Sie angeben, welchem Compartment sie zugeordnet werden soll. Dadurch wird kontrolliert, wer die Policy später ändern oder löschen kann. Je nach dem Design Ihrer Compartment-Hierarchie können Sie sie dem Mandanten, einem übergeordneten Element oder dem Compartment selbst zuordnen. Weitere Informationen finden Sie unter Policy-Zuordnung.

Ressourcen in einem Compartment einfügen

Um eine neue Ressource in einem Compartment einzufügen, geben Sie dieses Compartment einfach beim Erstellen der Ressource an (das Compartment ist eine der erforderlichen Informationen zum Erstellen einer Ressource). Wenn Sie in der Konsole arbeiten, müssen Sie zunächst das Compartment anzeigen, in dem Sie die Ressource erstellen möchten. Beachten Sie, dass sich die meisten IAM-Ressourcen im Mandanten befinden (dazu gehören Benutzer, Gruppen, Compartments und Policys, die dem Mandanten zugeordnet sind) und nicht in einem bestimmten Compartment erstellt oder verwaltet werden können.

Ressourcen in Compartments ermitteln

Mit dem Ressourcenmanager können Sie bereitgestellte Ressourcen als Terraform-Konfigurations- und Statusdateien mit Ressourcen-Discovery erfassen. Der erstellte Stack liefert eine Terraform-Konfiguration, mit der Sie Ihre IT-Infrastruktur als "Infrastructure-as-Code" programmgesteuert verwalten, versionieren und persistieren können.

Ein aus einem Compartment erstellter Stack stellt alle unterstützten Ressourcen im gesamten Compartment mit entsprechendem Geltungsbereich dar. Wenn Sie das Root Compartment für Ihren Mandanten auswählen, ist der Geltungsbereich die Mandantenebene, wie Benutzer und Gruppen. Wenn Sie ein Nicht-Root Compartment auswählen, ist der Geltungsbereich die Compartment-Ebene, wie Compute-Instanzen.

Die Stackerstellung wird nur aus einem einzelnen Compartment unterstützt. Stacks können nicht aus Nested Compartments erstellt werden.

Anweisungen finden Sie unter Stack aus einem vorhandenen Compartment erstellen.

Auswirkungen beim Verschieben von Compartments

Sie können ein Compartment in ein anderes übergeordnetes Compartment innerhalb desselben Mandanten verschieben. Wenn Sie ein Compartment verschieben, wird der gesamte Inhalt (Sub-Compartments und Ressourcen) mit diesem Compartment verschoben. Das Verschieben eines Compartments hat Auswirkungen auf den Inhalt. Diese Auswirkungen werden in den folgenden Abschnitten beschrieben. Sie sollten sich mit diesen Auswirkungen vertraut machen, bevor Sie ein Compartment verschieben.

Erforderliche IAM Policy

Um ein Compartment zu verschieben, müssen Sie zu einer Gruppe mit manage all-resources-Berechtigungen für das niedrigste gemeinsame übergeordnete Compartment des aktuellen Compartments und des Ziel-Compartments gehören.

Einschränkungen beim Verschieben von Compartments

Ein Compartment kann nicht verschoben werden, wenn die Quelle oder das Ziel Teil einer Sicherheitszone ist. Mit der Konsole Sicherheitszonen verwalten Sie die Compartments in einer Sicherheitszone.

Sie können ein Compartment nicht in ein Ziel-Compartment mit demselben Namen wie das verschobene Compartment verschieben.

Beispiel: Angenommen, Compartment A und Compartment B sind untergeordnete Elemente des Root-Compartments. Unter Compartment A befindet sich ein Sub-Compartment, das ebenfalls den Namen "Compartment B" trägt. Sie können Compartment B nicht in das übergeordnete Compartment B verschieben.

Compartment B kann nicht in ein übergeordnetes Compartment mit dem Namen "Compartment B" verschoben werden


Element	Beschreibung
	Zwei Compartments innerhalb desselben Elternteils können nicht denselben Namen haben. Deshalb können Sie ein Compartment nicht in ein Ziel-Compartment verschieben, in dem bereits ein Compartment mit demselben Namen vorhanden ist.

Policy-Auswirkungen beim Verschieben eines Compartments

Nachdem Sie ein Compartment in ein neues übergeordnetes Compartment verschoben haben, werden die Zugriffs-Policys des neuen übergeordneten Elements wirksam und die Policys des vorherigen übergeordneten Elements werden nicht mehr angewendet. Stellen Sie Folgendes sicher, bevor Sie ein Compartment verschieben:

Sie kennen die Policys, die den Zugriff auf das Compartment an seiner aktuellen Position regeln.
Sie kennen die Policys im neuen übergeordneten Compartment, die wirksam werden, wenn Sie das Compartment verschieben.

In einigen Fällen werden beim Verschieben von verschachtelten Compartments mit Policys, die die Hierarchie angeben, die Policys automatisch aktualisiert, um die Konsistenz sicherzustellen.

Policy-Beispiele

Gruppen mit Berechtigungen im aktuellen Compartment verlieren den Zugriff; Gruppen mit Berechtigungen im Ziel-Compartment erhalten Zugriff

In der folgenden Abbildung wird eine Compartment-Hierarchie dargestellt, in der Compartment C, ein untergeordnetes Element von A:B, in die Hierarchie A:D verschoben wird.

Compartment C wird von A:B in A:D verschoben


Element	Beschreibung
	Für den Mandanten sind die folgenden Policys für Compartments B und D definiert: Policy1: `Allow group G1 to manage instance-family in compartment A:B`
	Auswirkung, wenn Compartment C von B in D verschoben wird: Policy2: `Allow group G2 to manage instance-family in compartment A:D`

Gruppe G1 verliert die Berechtigung "manage instance-families" in Compartment C.
Gruppe G2 erhält die Berechtigung "manage instance-families" in Compartment C.

Stellen Sie sicher, dass Sie nicht nur wissen, welche Gruppen Berechtigungen verlieren, wenn Sie ein Compartment verschieben, sondern auch welche Gruppen Berechtigungen erhalten.

Automatische Aktualisierung von Policys

Wenn Sie ein Compartment verschieben, werden einige Policys automatisch aktualisiert. Policys, mit denen die Compartment-Hierarchie bis zum verschobenen Compartment angegeben wird, werden automatisch aktualisiert, wenn die Policy einem gemeinsamen Vorgänger des aktuellen und des übergeordneten Zielelements zugeordnet ist. Beachten Sie folgende Beispiele:

Beispiel 1: Policy wird automatisch aktualisiert

Policy wird automatisch aktualisiert, wenn die Policy einem gemeinsamen Vorgänger zugeordnet ist


Element	Beschreibung
	Policy: `Allow group G1 to manage buckets in compartment Test:A`
	Policy: `Allow group G1 to manage buckets in compartment Dev:A`
	Die Policy wird automatisch aktualisiert. Gruppe G1 verliert keine Berechtigungen.

In diesem Beispiel verschieben Sie Compartment A von "Operations:Test" in "Operations:Dev". Die Policy, der das Compartment A unterliegt, ist dem gemeinsamen übergeordneten Element "Operations" zugeordnet. Wenn das Compartment verschoben wird, wird die Policy-Anweisung vom IAM-Service automatisch mit dem neuen Compartment-Speicherort aktualisiert.

Es ist kein manuelles Eingreifen erforderlich, damit die Gruppe G1 weiter auf Compartment A in ihrem Speicherort zugreifen kann.

Beispiel 2: Policy wird nicht aktualisiert


Element	Beschreibung
	Policy: Zulassen, dass Gruppe G1 Buckets im Compartment A verwaltet
	Policy: Zulassen, dass Gruppe G1 Buckets im Compartment A verwaltet
	Die Policy wird nicht aktualisiert. Gruppe G1 verliert diese Berechtigung. Diese Policy ist ungültig und muss manuell entfernt werden.

In diesem Beispiel verschieben Sie Compartment A von "Operations:Test" in "Operations:Dev". Die Policy, der das Compartment A unterliegt, ist jedoch direkt dem Compartment "Test" zugeordnet. Wenn das Compartment verschoben wird, wird die Policy nicht automatisch aktualisiert. Die Policy für Compartment A ist nicht mehr gültig und muss manuell entfernt werden. Gruppe G1 hat keinen Zugriff mehr auf Compartment A im neuen Speicherort unter "Dev". Wenn keine andere Policy vorhanden ist, die der Gruppe G1 den Zugriff erteilt, müssen Sie eine neue Policy erstellen, damit G1 weiterhin Buckets in Compartment A verwalten kann.

Beispiel 3: Dem Mandanten zugeordnete Policy wird aktualisiert


Element	Beschreibung
	Policy: Zulassen, dass Gruppe G1 Buckets im Compartment "Operations:Test:A" verwaltet
	Policy: Zulassen, dass Gruppe G1 Buckets im Compartment "HR:Prod:A" verwaltet
	Die Policy wird automatisch aktualisiert. Gruppe G1 verliert keine Berechtigungen.

In diesem Beispiel verschieben Sie Compartment A von "Operations:Test" in "HR:Prod". Die Policy, der das Compartment A unterliegt, ist dem Mandanten zugeordnet, der ein gemeinsamer Vorgänger des ursprünglichen übergeordneten Compartments und des neuen übergeordneten Compartments ist. Wenn das Compartment verschoben wird, wird die Policy-Anweisung vom IAM-Service automatisch mit dem neuen Compartment-Speicherort aktualisiert.

Auswirkungen der Compartment-Quota beim Verschieben eines Compartments

Wenn Sie ein Compartment in ein anderes verschieben, werden Ressourcenkontingente im Ziel-Compartment nicht geprüft und nicht erzwungen. Wenn das Verschieben des Compartments zu einer Quota-Verletzung im Ziel-Compartment führt, wird das Verschieben daher nicht blockiert. Wenn das Verschieben abgeschlossen ist, weist das Ziel-Compartment den Status "Quota überschritten" auf. Sie können keine neuen Ressourcen erstellen, die die Quota überschreiten, bis Sie die Quota für das Ziel-Compartment anpassen oder Ressourcen entfernen, damit sie mit der vorhandenen Quota konform sind. Weitere Informationen zur Verwaltung von Compartment-Quotas finden Sie unter Compartment-Quotas - Überblick.

Auswirkungen des Taggings beim Verschieben eines Compartments

Tags werden nach dem Verschieben eines Compartments nicht automatisch aktualisiert. Wenn Sie eine Taggingstrategie basierend auf dem Compartment implementiert haben, müssen Sie die Tags in den Ressourcen nach dem Verschieben aktualisieren. Beispiel: Angenommen, "CompartmentA" hat ein untergeordnetes Compartment "CompartmentB". "CompartmentA" ist mit Tagstandardwerten eingerichtet, sodass jede Ressource in "CompartmentA" mit "TagA" getaggt ist. Deshalb sind "CompartmentB" und alle zugehörigen Ressourcen mit dem Standardtag "TagA" getaggt. Wenn Sie "CompartmentB" in "CompartmentC" verschieben, werden die Standardtags weiterhin von "CompartmentA" verwendet. Wenn Sie Standardtags für "CompartmentC" eingerichtet haben, müssen Sie diese den Ressourcen im verschobenen Compartment hinzufügen.

Tagstandards werden nicht aktualisiert, nachdem ein Compartment verschoben wurde


Element	Beschreibung
	Alle Ressourcen in "CompartmentB" werden mit den Standardtags getaggt, die für das übergeordnete Element "CompartmentA" definiert sind.
	Wenn CompartmentB in CompartmentC verschoben wird, werden die Standardtags nicht aktualisiert. Für CompartmentB werden weiterhin die Standardtags aus CompartmentA angewendet.

Oracle Cloud Infrastructure - Dokumentation