Mit einem Projektmigrationsplan können Sie die Bereitschaft der Organisation bewerten und Dienstunterbrechungen verhindern, bevor Sie ein Projekt zwischen Organisationsressourcen verschieben. Ein Inventar der aktiven Dienste und Abhängigkeiten hilft Ihnen auch, vorherzusehen, wie sich die Zielressourcenhierarchie auf Ihre Arbeitslasten auswirkt.
Während einer Verschiebung behandelt die Cloud Resource Manager API das Projekt und die zugrunde liegenden Dienste als eine Einheit ohne interne Konfigurationsänderungen. Geerbte Zulassungs-, Ablehnungs- und Organisationsrichtlinien werden jedoch nicht mit dem Projekt migriert, während direkt angehängte Richtlinien und Dienstkonten beibehalten werden. Diese Hierarchieänderung kann zu unerwartetem Verhalten führen oder Verstöße gegen Organisationsrichtlinien in der Zielorganisation auslösen.
Inventarübersicht
Verwenden Sie Cloud Asset Inventory, um eine Übersicht der verwendeten Ressourcen zu erstellen, einschließlich Zulassungsrichtlinien. Anhand dieser Übersicht können Sie Ihren Migrationsplan erstellen.
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.
Eine Liste aller Zulassungs- und Ablehnungsrichtlinien, die sich auf den Zugriff auf ein Projekt auswirken, finden Sie unter Alle Zulassungs- und Ablehnungsrichtlinien ansehen, die für eine Ressource gelten.
Richtlinienüberprüfung
Wenn Sie Ihr Projekt migrieren, übernimmt es nicht mehr die Richtlinien von seinem aktuellen Platz in der Ressourcenhierarchie und unterliegt 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. Wenn Sie Richtlinien direkt auf das Projekt anwenden, können Sie prüfen, ob die richtigen Richtlinien ab dem Zeitpunkt der Migration angewendet werden.
Zulassungs-, Ablehnungs- und Organisationsrichtlinien werden über die Ressourcenhierarchie übernommen und können die Funktion eines Dienstes blockieren, wenn sie nicht richtig festgelegt sind. Ermitteln Sie die effektive Richtlinie am Ziel des Projekts in Ihrer Ressourcenhierarchie, um sicherzustellen, dass die Richtlinie Ihren Governance-Zielen entspricht.
Verschlüsselte Schlüssel verwalten
Prüfen Sie, ob für Ihr Projekt ein kundenverwalteter Verschlüsselungsschlü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.
Funktionen in der Vorabversion
Sie können Funktionen in der Vorabversion für Organisationsressourcen, Ordner oder Projekte aktivieren. Wenn Sie ein Alpha- oder Beta-Feature für das zu migrierende Projekt aktiviert haben, sollte dieses Feature nach der Migration weiterhin funktionieren. Wenn die Funktion in der Vorabversion privat ist und nicht zur Zulassungsliste für die Zielorganisationsressource hinzugefügt wurde, können Sie nach Abschluss der Migration keine Konfigurationsänderungen vornehmen.
Neues Rechnungskonto identifizieren
Cloud-Rechnungskonten können organisationsressourcenübergreifend verwendet werden. Das Verschieben eines Projekts von einer Organisationsressource in eine andere hat keine Auswirkungen auf die Abrechnung. Die Gebühren werden weiterhin über das alte Rechnungskonto abgerechnet. Bei der Migration von Projekten zwischen Organisationsressourcen ist jedoch häufig auch eine Migration zu einem neuen Rechnungskonto erforderlich.
Legen Sie im Rahmen Ihres Migrationsplans fest, ob Sie vorhandene Rechnungskonten beibehalten möchten. Sie können Projekte auch mit einem neuen Rechnungskonto in der Zielorganisationsressource verknüpfen.
Informationen zum Ändern oder Migrieren eines Rechnungskontos finden Sie unter Rechnungskonto ändern.
Rollback-Plan
Wenn Sie feststellen, dass etwas in einem der migrierten Projekte nicht 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 beim Migrieren eines Projekts unbeabsichtigte Auswirkungen haben, sowohl in den Quell- als auch in den Zielorganisationsressourcen. Sie können dieses Risiko minimieren, indem Sie bestimmte Ordner erstellen, die nur Projekte für den Export und Import enthalten, und dafür sorgen, dass die Ordner in beiden Organisationsressourcen dieselben Richtlinien übernehmen. Sie können auch Berechtigungen für diese Ordner festlegen, die von den darin verschobenen Projekten übernommen werden. Dadurch wird die Projektmigration beschleunigt.
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 für diese Ordner eine Organisationsrichtlinie 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 in der Zielorganisationsressource ebenfalls dedizierte Importordner 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 für diese Ordner eine Organisationsrichtlinie 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.