Bei einer Projektmigration müssen Sie bewerten, wie die Migration hat Auswirkungen auf die im Projekt ausgeführten Dienste. 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 Organisation Richtlinien und Dienstkonten, die direkt an die Ressource angehängt sind, werden migriert. Dies kann nach Abschluss der Migration zu unbeabsichtigtem Verhalten führen.
Je nach den Organisationsrichtlinien der Zielorganisationsressource kann die Migration Ihres Projekts auch zu Verstößen gegen die Organisationsrichtlinien führen.
Bevor Sie Ihr Projekt zwischen Organisationsressourcen migrieren, sollten Sie einen Migrationsplan erstellen, um die Bereitschaft Ihrer Organisationsressource und der Projekte zu ermitteln, zu migrieren. In diesem Migrationsplan inventarisieren Sie alle Dienste, die in Ihrem Projekt ausgeführt werden, sowie alle anderen Dienste, die von der Migration oder von der Ressourcenhierarchie am Zielort 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 sicherzustellen, dass ab dem Zeitpunkt der Migration die richtigen Richtlinien 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 eine Alpha- oder Betafunktion für das zu migrierende Projekt aktiviert haben, sollte diese Funktion nach der Migration weiterhin funktionieren. Wenn die Funktion in der Vorabversion privat ist und für die Zielorganisationsressource nicht auf der Zulassungsliste steht, können Sie nach Abschluss der Migration keine Konfigurationsänderungen vornehmen.
Rollback-Plan
Wenn Sie feststellen, dass etwas mit keinem der migrierten Projekte mehr funktioniert, können Sie es an seinem 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 Richtlinienübernahme kann unbeabsichtigte Auswirkungen haben, wenn Sie ein Projekt migrieren, sowohl in den Ressourcen der Quell- als auch der Zielorganisation. Sie können dieses Risiko mindern, indem Sie bestimmte Ordner erstellen, die nur Projekte für den Export und Import enthalten, und dafür sorgen, dass dieselben Ordner von den Ordnern in beiden Organisationen übernommen werden. Sie können auch Berechtigungen für diese Ordner festlegen, die von den darin verschobenen Projekten ü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, die Sie verwenden möchten.
Projekte zu exportieren. Legen Sie dann eine Organisationsrichtlinie für diese Ordner fest, jeweils mit
die constraints/resourcemanager.allowedExportDestinations-Einschränkung, die auf
Organisationsressource, 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 außerdem dedizierte Importordner in der Zielorganisationsressource ein, einen für jede Organisationsressource, aus der Sie Projekte importieren möchten. Erstellen Sie dazu für jede Organisationsressource der Quellorganisation, aus der Sie Projekte importieren möchten, einen Ordner. Legen Sie dann eine Organisationsrichtlinie für diese Ordner fest, wobei die Einschränkung constraints/resourcemanager.allowedImportSources jeweils 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 Identity and Access Management-Rollen und ‑Berechtigungen zuweisen.