Einen Migrationsplan erstellen

Bei einer Projektmigration müssen Sie abwägen, wie sich die Migration auf die im Projekt ausgeführten Dienste auswirkt. Die Resource Manager API behandelt die Projektressource und alle darunter ausgeführten Dienste als eine Einheit, d. h., es werden keine Konfigurationsänderungen innerhalb des Projekts angewendet.

Während die Migration keine direkten Konfigurationsänderungen am Projekt vornimmt, hat die Änderung der Ressourcenhierarchie wahrscheinlich Auswirkungen auf die Funktion des Projekts und seine laufenden Dienste. Übernommene Richtlinien wie Identity and Access Management oder Organisationsrichtlinien werden während der Migration nicht mit dem Projekt migriert. Die Organisationsrichtlinien und Dienstkonten, die direkt an die Ressource angehängt sind, werden migriert. Dies kann nach Abschluss der Migration zu unbeabsichtigtem Verhalten führen.

Die Migration Ihres Projekts kann je nach den Organisationsrichtlinien der Zielorganisationsressource auch zu Verstößen gegen Organisationsrichtlinien führen.

Bevor Sie Ihr Projekt zwischen Organisationsressourcen migrieren, sollten Sie einen Migrationsplan erstellen, um die Bereitschaft sowohl Ihrer Organisationsressource als auch der Projekte zu ermitteln, die Sie migrieren möchten. Machen Sie in diesem Migrationsplan eine Bestandsaufnahme der Dienste, die in Ihrem Projekt ausgeführt werden, sowie aller anderen Dienste, die von der Migration oder der Ressourcenhierarchie am Ziel Ihres Projekts betroffen sein könnten.

Inventarübersicht

Verwenden Sie Cloud Asset Inventory, um eine Übersicht der verwendeten Ressourcen zu erstellen, einschließlich der Richtlinien für die Identitäts- und Zugriffsverwaltung. Anhand dieser Übersicht können Sie Ihren Migrationsplan festlegen.

Sie können diese Daten auch mit Cloud Asset Inventory in BigQuery übertragen. So können Sie die Daten mit SQL abfragen. Dies ist im Vergleich zur Interpretation von Daten im JSON-Format einfacher. Informationen zum Exportieren dieser Daten finden Sie unter Nach BigQuery exportieren.

Richtlinienüberprüfung

Wenn Sie Ihr Projekt migrieren, werden die Richtlinien von ihrer aktuellen Stelle in der Ressourcenhierarchie nicht mehr übernommen und unterliegen nicht mehr der effektiven Richtlinienbewertung am Ziel. Achten Sie darauf, dass die effektiven Richtlinien am Ziel des Projekts so weit wie möglich den Richtlinien entsprechen, die das Projekt an seinem Quellspeicherort hat.

Jede Richtlinie, die direkt auf das Projekt angewendet wird, bleibt auch nach der Migration erhalten. Die direkte Anwendung von Richtlinien auf das Projekt ist eine gute Möglichkeit, um zu prüfen, ob die richtigen Richtlinien ab dem Abschluss der Migration angewendet werden.

Richtlinien der Identitäts- und Zugriffsverwaltung und Organisationsrichtlinien werden über die Ressourcenhierarchie übernommen und können bei Bedarf einen Dienst blockieren, damit er nicht mehr funktioniert. Ermitteln Sie die geltende Richtlinie am Ziel des Projekts in Ihrer Ressourcenhierarchie, damit die Richtlinie Ihren Governance-Zielen entspricht.

Verschlüsselte Schlüssel verwalten

Sie sollten prüfen, ob in Ihrem Projekt ein vom Kunden verwalteter verschlüsselter Schlüssel oder ein anderer Cloud Key Management Service aktiviert ist. Kryptografische Schlüssel gehören zum Projekt und ein Nutzer mit owner-Zugriff auf dieses Projekt kann daher kryptografische Vorgänge für Schlüssel in Cloud KMS in diesem Projekt verwalten und ausführen.

Weitere Informationen finden Sie unter Aufgabentrennung.

Vorschaufeatures

Sie können Vorschaufunktionen für Organisationsressourcen, Ordner oder Projekte aktivieren. Wenn Sie für das zu migrierende Projekt ein Alpha- oder Betafeature aktiviert haben, sollte dieses Feature nach der Migration weiterhin funktionieren. Wenn das Vorschaufeature privat ist und nicht auf der Zulassungsliste für die Zielorganisationsressource steht, können Sie nach Abschluss der Migration keine Änderungen an der Konfiguration vornehmen.

Rollback-Plan

Wenn Sie feststellen, dass bei einem der migrierten Projekte etwas nicht funktioniert, können Sie sie an ihrem ursprünglichen Speicherort wiederherstellen. Dazu müssen Sie die erforderlichen IAM-Berechtigungen haben und die erforderlichen Organisationsrichtlinien festlegen, damit Sie die Projektmigration umgekehrt ausführen können.

Eine Liste der erforderlichen Berechtigungen finden Sie unter Berechtigungen zuweisen. Informationen zu den Organisationsrichtlinien, die Sie konfigurieren müssen, um eine Projektmigration zuzulassen, finden Sie unter Organisationsrichtlinien konfigurieren.

Dedizierte Import- und Exportordner

Die Übernahme von Richtlinien kann unerwünschte Auswirkungen haben, wenn Sie ein Projekt sowohl in den Ressourcen der Quell- als auch der Zielorganisation migrieren. Sie können dieses Risiko verringern, indem Sie bestimmte Ordner erstellen, die nur Projekte für den Export und Import enthalten, und dafür sorgen, dass dieselben Richtlinien von den Ordnern in beiden Organisationsressourcen übernommen werden. Sie können auch Berechtigungen für diese Ordner festlegen, die auf die darin verschobenen Projekte übernommen werden, um den Projektmigrationsprozess zu beschleunigen.

Erwägen Sie bei der Migrationsplanung, zuerst einen dedizierten Quellordner zu erstellen. Erstellen Sie dazu einen Ordner für jede Zielorganisationsressource, in die Sie Projekte exportieren möchten. Legen Sie dann eine Organisationsrichtlinie für diese Ordner fest, wobei die Einschränkung constraints/resourcemanager.allowedExportDestinations jeweils auf die einzelne Organisationsressource festgelegt ist, in die Sie Projekte exportieren möchten.

Sie können beispielsweise Export to Marketing Org- und Export to Sales Org-Ordner mit jeweils entsprechenden Einschränkungen für Organisationsrichtlinien einrichten.

Richten Sie auf ähnliche Weise dedizierte Importordner in der Zielorganisationsressource ein, einen für jede Organisationsressource, aus der Sie Projekte importieren möchten. Erstellen Sie dazu einen Ordner für jede Quellorganisationsressource, aus der Sie Projekte importieren möchten. Legen Sie dann eine Organisationsrichtlinie für diese Ordner fest, wobei jeweils die Einschränkung constraints/resourcemanager.allowedImportSources auf die einzelne Organisationsressource festgelegt ist, aus der Sie Projekte importieren möchten.

Sie können beispielsweise Import from Marketing Org- und Import from App Development Org-Ordner mit jeweils entsprechenden Einschränkungen für Organisationsrichtlinien einrichten.

Weisen Sie in jedem der Import- und Exportordner der Person, die die Projekte verschieben wird, die Rolle roles/resourcemanager.projectMover zu. Diese Rolle wird von allen Projekten übernommen, die in diesen Ordnern enthalten sind. So kann der Nutzer die Verschiebungsvorgänge für jedes Projekt ausführen, das in diese Ordner verschoben wird.

Nach Abschluss der Projektmigration sollten Sie diese dedizierten Ordner entfernen.

Informationen zum Festlegen von Organisationsrichtlinien finden Sie unter Organisationsrichtlinien konfigurieren.

Nächste Schritte

Informationen zum Zuweisen von Identity and Access Management-Rollen und -Berechtigungen für die Migration von Projekten zwischen Organisationen finden Sie unter IAM-Rollen und -Berechtigungen zuweisen.