Vous pouvez déplacer un projet Google Cloud vers un nouvel emplacement dans la hiérarchie de vos ressources en mettant à jour ses métadonnées. Avant de migrer un projet vers une nouvelle organisation, examinez l'impact de la migration sur les ressources et les configurations du projet.
Projets dans la hiérarchie des ressources
La ressource "Projet" est l'entité d'organisation de base dans une ressource d'organisation Google Cloud. Les projets sont créés sous des ressources d'organisation et peuvent être placés sous des dossiers ou sous la ressource d'organisation elle-même, formant ainsi la hiérarchie des ressources.
Vous devrez peut-être migrer des projets entre des ressources d'organisation en raison d'acquisitions, d'exigences réglementaires ou de la séparation d'unités commerciales. Vous pouvez utiliser l'API Resource Manager pour migrer ces projets. L'opération de migration renvoie une chaîne représentant le nom de l'opération. L'API vous permet également d'effectuer un rollback de la migration, en replaçant le projet à son emplacement d'origine dans la hiérarchie si nécessaire.
Scénarios de migration
L'emplacement de votre projet détermine l'un des deux chemins d'accès que vous empruntez :
- Migrer des projets d'une organisation vers une autre ressource d'organisation
- Migrer un projet autonome (créé sans organisation) vers la hiérarchie d'une ressource d'organisation.
Si vous devez déplacer un projet vers Aucune organisation après l'avoir associé à une ressource Organisation, vous devez contacter Cloud Customer Care. Le rollback en libre-service d'une organisation vers l'absence d'organisation n'est pas possible.
En plus de l'API, vous pouvez également utiliser la console Google Cloud pour déplacer des projets en sélectionnant le projet et en lui attribuant une nouvelle destination parente.
Identifier l'état actuel du projet
Avant de commencer, vous devez déterminer si votre projet est associé à une ressource d'organisation. Cela détermine si vous suivez le parcours Organisation à organisation ou le parcours Aucune organisation.
Si vous ne disposez pas de l'autorisation resourcemanager.organizations.get sur la ressource d'organisation parente du projet, il est probable que vos projets ne s'affichent pas comme prévu sous l'organisation réelle dans la consoleGoogle Cloud . Cela peut donner l'impression que le projet n'est associé à aucune ressource d'organisation.
Pour déterminer si le projet est associé à une ressource d'organisation, exécutez la commande suivante :
gcloud
gcloud projects get-ancestors PROJECT_ID
Remplacez PROJECT_ID par l'ID du projet que vous souhaitez migrer.
Si le résultat inclut un type de ressource organization dans la hiérarchie, votre projet fait déjà partie d'une hiérarchie d'organisation.
Si le type organization est manquant ou vide, le projet est un projet autonome sans ressource d'organisation.
En fonction de l'état de votre projet, suivez le guide approprié :
- Si vous souhaitez migrer des projets créés sans organisation associée, consultez Migrer des projets qui ne sont pas associés à une ressource d'organisation.
- Si vous souhaitez migrer des projets d'une organisation vers une autre ressource d'organisation, consultez Migrer des projets entre des ressources d'organisation.
Fonctionnement de la migration
La migration d'un projet n'est pas un transfert de données. Vos services, bases de données et instances de machine virtuelle (VM) restent actifs et ne subissent aucun temps d'arrêt. À la place, la migration met à jour la ressource parente du projet. Comme Google Cloud suit un modèle d'héritage hiérarchique, la stratégie de sécurité du projet change dès qu'il est associé à un nouveau parent.
| Fonctionnalité | État | Impact |
|---|---|---|
| ID du projet et numéro | Inchangé | Les clés API, les noms de service et les ID codés en dur restent inchangés. |
| Données et ressources | Inchangé | Les VM, les buckets de stockage et les bases de données restent en ligne. |
| Rôles IAM directs | Inchangé | Les rôles attribués directement au projet sont déplacés avec lui. |
| Rôles IAM hérités | Modifications | Les rôles attribués au niveau de l'organisation ou du dossier source sont perdus. |
| Règles d'administration | Modifications | Les contraintes sources sont remplacées par les contraintes de destination. |
| Quotas | Modifications | Les quotas hérités au niveau de l'organisation sont perdus, mais les quotas au niveau du projet sont conservés. |
| Compte de facturation | Inchangé | Le projet reste associé au compte de facturation d'origine. |
Impact sur les quotas
Si vous avez défini des quotas au niveau d'une ressource, les aspects suivants sont appliqués après la migration :
- Les quotas définis au niveau du projet restent inchangés.
- Les quotas définis au niveau de la ressource d'organisation ne sont pas transférés. L'organisation perd tous les quotas ou remplacements de quotas hérités.
Les pages suivantes permettent de déterminer les quotas appliqués à une ressource d'organisation :
- Afficher et gérer les quotas
- Lister les quotas avec gcloud
- Lister les quotas avec RPC
- Exemple de bucket de quota
Exemple
$ gcloud alpha services quota list --service=compute.googleapis.com --consumer=projects/workloadyee --filter="metric: compute.googleapis.com/cpus"
...
- defaultLimit: '600'
dimensions:
region: us-central1
effectiveLimit: '650'
...
Considérations importantes
Avant de commencer une migration, examinez ces zones à haut risque pour éviter toute interruption de service :
Limites de quota : si l'organisation de destination a des limites de quota inférieures à celles de la source, votre projet peut dépasser son quota à l'arrivée.
Inventaire des éléments : la propagation complète des mises à jour de la liste complète des ressources dans l'inventaire des éléments cloud peut prendre quelques jours après la migration.
Coûts et remises : si l'organisation d'origine bénéficiait de remises basées sur les SKU ou de remises du programme Enterprise Discount Program (EDP), ces remises ne s'appliquent pas à la nouvelle organisation tant que vous ne les avez pas négociées avec votre représentant commercial Google. Les remises sur engagement d'utilisation et les achats Google Cloud Marketplace peuvent également nécessiter un rachat.
Niveaux d'assistance : s'il n'existe aucun contrat d'assistance actif ou si le niveau d'assistance est inférieur dans l'organisation de destination, vous risquez de perdre votre niveau d'assistance actuel.
Rôles personnalisés : si votre projet repose sur des rôles IAM personnalisés définis au niveau de l'organisation, ces rôles n'existeront pas dans la destination. Recréez-les dans l'organisation de destination avant de procéder au déplacement.
La feuille de route de migration
Utilisez la feuille de route suivante pour naviguer dans le processus de migration de projet :
- Préparation : créez un plan de migration pour coordonner le calendrier.
- Exécution : attribuez des rôles IAM, configurez des règles d'administration et exécutez la migration.
- Vérification : effectuez les tâches post-migration, comme l'audit des règles héritées et la mise à jour de la facturation.