Per la migrazione di un progetto, è necessario valutare l'impatto della migrazione sui servizi in esecuzione all'interno del progetto. L'API Resource Manager considera la risorsa progetto e tutti i servizi in esecuzione al suo interno come un'unica unità, il che significa che non verranno applicate modifiche alla configurazione all'interno del progetto.
Sebbene la migrazione non apporti modifiche dirette alla configurazione del progetto, la modifica della gerarchia delle risorse avrà probabilmente un impatto sul funzionamento del progetto e dei servizi in esecuzione. Le policy dell'organizzazione consentite, negate o ereditate anziché associate direttamente al progetto non verranno migrate con il progetto durante la migrazione. Verrà eseguita la migrazione dei criteri dell'organizzazione e dei service account collegati direttamente alla risorsa. Ciò potrebbe causare un comportamento imprevisto al termine della migrazione.
La migrazione del progetto potrebbe anche comportare violazioni dei criteri dell'organizzazione, a seconda dei criteri dell'organizzazione della risorsa dell'organizzazione di destinazione.
Prima di eseguire la migrazione del progetto tra le risorse dell'organizzazione, ti consigliamo di creare un piano di migrazione per determinare la preparazione sia della risorsa dell'organizzazione sia dei progetti di cui vuoi eseguire la migrazione. In questo piano di migrazione, fai l'inventario di ciascuno dei servizi in esecuzione nel tuo progetto e di qualsiasi altro servizio che potrebbe essere interessato dalla migrazione o dalla gerarchia delle risorse nella destinazione del tuo progetto.
Panoramica dell'inventario
Utilizza Cloud Asset Inventory per creare una panoramica delle risorse in uso, inclusi i criteri di autorizzazione. Puoi utilizzare questa panoramica per definire il piano di migrazione.
Puoi anche utilizzare Cloud Asset Inventory per trasferire questi dati in BigQuery. In questo modo potrai eseguire query sui dati utilizzando SQL, che è più facile da leggere rispetto all'interpretazione dei dati in formato JSON. Per informazioni sull'esportazione di questi dati, consulta Esportazione in BigQuery.
Per ottenere un elenco di tutti i criteri di autorizzazione e negazione che influiscono sull'accesso a un progetto, consulta Visualizzare tutti i criteri di autorizzazione e negazione applicabili a una risorsa.
Verifica delle norme
Quando esegui la migrazione del progetto, questo non erediterà più le policy dalla sua posizione attuale nella gerarchia delle risorse e sarà soggetto alla valutazione delle policy effettive nella destinazione. Ti consigliamo di assicurarti che le norme effettive nella destinazione del progetto corrispondano il più possibile alle norme che il progetto aveva nella posizione di origine.
Qualsiasi criterio applicato direttamente al progetto verrà comunque allegato al termine della migrazione. L'applicazione diretta dei criteri al progetto è un buon modo per verificare che i criteri corretti vengano applicati dal momento in cui la migrazione è completata.
Le policy di autorizzazione, negazione e dell'organizzazione vengono ereditate tramite la gerarchia delle risorse e possono impedire il funzionamento di un servizio se non sono impostate correttamente. Determina la policy effettiva nella destinazione del progetto nella gerarchia delle risorse per assicurarti che sia in linea con i tuoi obiettivi di governance.
Gestire le chiavi criptate
Devi verificare se il tuo progetto ha una chiave criptata gestita dal cliente o se è abilitato un altro
Cloud Key Management Service. Le chiavi crittografiche sono di proprietà del progetto e un utente con accesso owner a quel progetto potrà quindi gestire ed eseguire operazioni crittografiche sulle chiavi in Cloud KMS in quel progetto.
Per saperne di più, consulta la sezione Separazione dei compiti.
Funzionalità in anteprima
Puoi attivare le funzionalità di anteprima per le risorse, le cartelle o i progetti dell'organizzazione. Se hai abilitato una funzionalità alpha o beta nel progetto da migrare, questa dovrebbe continuare a funzionare dopo la migrazione. Se la funzionalità di anteprima è privata e non è inclusa nella lista consentita per la risorsa dell'organizzazione di destinazione, non potrai apportare modifiche alla configurazione dopo il completamento della migrazione.
Piano di rollback
Se riscontri problemi con uno dei progetti che hai migrato, puoi ripristinarli nella posizione originale. Per farlo, devi disporre delle autorizzazioni IAM necessarie e impostare i criteri dell'organizzazione richiesti in modo da poter eseguire la migrazione del progetto al contrario.
Per un elenco delle autorizzazioni richieste, vedi Assegnare autorizzazioni. Per le policy dell'organizzazione che devi configurare per consentire la migrazione di un progetto, consulta Configurare le policy dell'organizzazione.
Cartelle di importazione ed esportazione dedicate
L'ereditarietà dei criteri può causare effetti indesiderati durante la migrazione di un progetto, sia nelle risorse dell'organizzazione di origine che in quelle di destinazione. Puoi mitigare questo rischio creando cartelle specifiche per contenere solo i progetti da esportare e importare e assicurandoti che le stesse policy vengano ereditate dalle cartelle in entrambe le risorse dell'organizzazione. Puoi anche impostare le autorizzazioni per queste cartelle che verranno ereditate dai progetti spostati al loro interno, contribuendo ad accelerare il processo di migrazione dei progetti.
Quando pianifichi una migrazione, ti consigliamo di configurare prima una cartella di origine dedicata.
A questo scopo, crea una cartella per ogni risorsa dell'organizzazione di destinazione in cui prevedi di
esportare i progetti. Poi, imposta un criterio dell'organizzazione su queste cartelle, ciascuna con
il vincolo constraints/resourcemanager.allowedExportDestinations impostato sulla
singola risorsa dell'organizzazione a cui vuoi esportare i progetti.
Ad esempio, potresti configurare le cartelle Export to Marketing Org e
Export to Sales Org, ciascuna con i vincoli dei criteri dell'organizzazione
appropriati.
Allo stesso modo, configura cartelle di importazione dedicate nella risorsa organizzazione di destinazione, una per ogni risorsa organizzazione da cui vuoi importare i progetti. Per farlo, crea una cartella per ogni risorsa dell'organizzazione di origine da cui
intendi importare i progetti. Poi, imposta un criterio dell'organizzazione su queste cartelle,
ognuna con il vincolo constraints/resourcemanager.allowedImportSources impostato
sulla singola risorsa dell'organizzazione da cui vuoi importare i progetti.
Ad esempio, potresti configurare le cartelle Import from Marketing Org e
Import from App Development Org, ognuna con i vincoli dei criteri
dell'organizzazione appropriati.
In ognuna delle cartelle di importazione ed esportazione, assegna il ruolo roles/resourcemanager.projectMover alla persona che sposterà i progetti. Questo ruolo verrà ereditato da tutti i progetti contenuti in queste cartelle, consentendo all'utente di eseguire le operazioni di spostamento su qualsiasi progetto spostato in queste cartelle.
Una volta completata la migrazione del progetto, devi rimuovere queste cartelle dedicate.
Per informazioni sull'impostazione delle policy dell'organizzazione, consulta Configurare le policy dell'organizzazione.
Passaggi successivi
Per assegnare ruoli e autorizzazioni Identity and Access Management per la migrazione dei progetti tra organizzazioni, consulta Assegnare ruoli e autorizzazioni Identity and Access Management.