Per la migrazione di un progetto, è necessario valutare l'impatto della migrazione sui servizi in esecuzione all'interno del progetto. L'API Resource Manager tratta la risorsa progetto e tutti i servizi in esecuzione al di sotto come una singola 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, è probabile che la modifica della gerarchia delle risorse abbia un impatto sulla funzione del progetto e dei servizi in esecuzione. Le policy di autorizzazione, negazione o dell'organizzazione ereditate anziché collegate direttamente al progetto non verranno migrate con il progetto durante la migrazione. Le policy dell'organizzazione e gli account di servizio collegati direttamente alla risorsa verranno migrati. Questo potrebbe causare un comportamento imprevisto al termine della migrazione.
La migrazione del progetto potrebbe anche comportare violazioni delle policy dell'organizzazione, a seconda delle policy dell'organizzazione della risorsa organizzazione di destinazione.
Prima di eseguire la migrazione del progetto tra le risorse organizzazione, ti consigliamo di creare un piano di migrazione per determinare la preparazione sia della risorsa organizzazione sia dei progetti di cui vuoi eseguire la migrazione. In questo piano di migrazione, inventaria ciascuno dei servizi in esecuzione nel progetto e tutti gli altri servizi che potrebbero essere interessati dalla migrazione o dalla gerarchia delle risorse nella destinazione del progetto.
Panoramica del modulo Inventario
Utilizza Cloud Asset Inventory per creare una panoramica delle risorse in uso, incluse le policy 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 Esportare in BigQuery.
Per visualizzare un elenco di tutte le policy di autorizzazione e negazione che influiscono sull'accesso a un progetto, consulta Visualizzare tutte le policy di autorizzazione e negazione applicate a una risorsa.
Verifica delle policy
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 sua destinazione. Ti consigliamo di assicurarti che le policy effettive nella destinazione del progetto corrispondano il più possibile alle policy che il progetto aveva nella posizione di origine.
Qualsiasi policy applicata direttamente al progetto rimarrà collegata al termine della migrazione. L'applicazione delle policy direttamente al progetto è un buon modo per verificare che le policy corrette vengano applicate 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 la policy 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 un altro Cloud Key Management Service abilitato. Le chiavi di crittografia sono di proprietà del progetto e un utente con accesso owner a quel progetto potrà quindi gestire ed eseguire operazioni di crittografia sulle chiavi in Cloud KMS in quel progetto.
Per ulteriori informazioni, consulta Separazione dei compiti.
Funzionalità in anteprima
Puoi abilitare le funzionalità in anteprima nelle risorse organizzazione, nelle cartelle o nei progetti. Se hai abilitato una funzionalità alpha o beta nel progetto di cui eseguire la migrazione, questa funzionalità dovrebbe continuare a funzionare dopo la migrazione. Se la funzionalità in anteprima è privata e non è stata aggiunta all'elenco consentiti per la risorsa organizzazione di destinazione, non potrai apportare modifiche alla configurazione al termine della migrazione.
Identificare il nuovo account di fatturazione
Gli account di fatturazione Cloud possono essere utilizzati nelle risorse organizzazione. Lo spostamento di un progetto da una risorsa organizzazione a un'altra non influisce sulla fatturazione. Gli addebiti continuano a essere applicati al vecchio account di fatturazione. Tuttavia, la migrazione dei progetti tra le risorse organizzazione spesso include anche il requisito di eseguire la migrazione a un nuovo account di fatturazione.
Nell'ambito del piano di migrazione, determina se mantenere gli account di fatturazione esistenti. Puoi anche associare i progetti a un nuovo account di fatturazione nella risorsa organizzazione di destinazione.
Per scoprire come modificare o migrare un account di fatturazione, consulta Modificare l'account di fatturazione.
Piano di rollback
Se scopri che qualcosa non funziona in uno dei progetti di cui hai eseguito la migrazione, puoi ripristinarli nella posizione originale. Per farlo, devi disporre delle autorizzazioni IAM necessarie e impostare le policy dell'organizzazione richieste in modo da poter eseguire la migrazione del progetto al contrario.
Per un elenco delle autorizzazioni richieste, consulta Assegnare le 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à delle policy può causare effetti imprevisti durante la migrazione di un progetto, sia nelle risorse organizzazione di origine che in quelle di destinazione. Puoi mitigare questo rischio creando cartelle specifiche per contenere solo i progetti per l'esportazione e l'importazione e assicurandoti che le stesse policy vengano ereditate dalle cartelle in entrambe le risorse 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 del progetto.
Quando pianifichi una migrazione, ti consigliamo di configurare prima una cartella di origine dedicata.
Per farlo, crea una cartella per ogni risorsa organizzazione di destinazione in cui prevedi di esportare i progetti. Quindi, imposta una policy dell'organizzazione su queste cartelle, ognuna con il vincolo constraints/resourcemanager.allowedExportDestinations impostato sulla singola risorsa organizzazione in cui vuoi esportare i progetti.
Ad esempio, puoi configurare le cartelle Export to Marketing Org e Export to Sales Org, ognuna con i vincoli delle policy dell'organizzazione appropriati impostati.
Allo stesso modo, configura le 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 organizzazione di origine da cui prevedi di importare i progetti. Quindi, imposta una policy dell'organizzazione su queste cartelle, ognuna con il vincolo constraints/resourcemanager.allowedImportSources impostato sulla singola risorsa organizzazione da cui vuoi importare i progetti.
Ad esempio, puoi configurare le cartelle Import from Marketing Org e Import from App Development Org, ognuna con i vincoli delle policy dell'organizzazione appropriati impostati.
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.
Al termine della 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 di Identity and Access Management per la migrazione dei progetti tra le organizzazioni, consulta Assegnare ruoli e autorizzazioni di Identity and Access Management.