La migration d'un projet Google Cloud est une opération de métadonnées qui modifie l'emplacement du projet dans la hiérarchie des ressources. Cette page explique comment fonctionnent les migrations, ce qui reste identique et ce qui change lorsqu'un projet est transféré vers une autre organisation.
Projets dans la hiérarchie des ressources
La ressource "Projet" constitue l'entité d'organisation de base dans une ressource d'organisation Google Cloud. Les projets sont créés dans des ressources d'organisation et peuvent être placés dans des dossiers ou dans la ressource d'organisation elle-même, formant 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 des unités commerciales. Vous pouvez utiliser l'API Resource Manager pour migrer ces projets. L'API vous permet également d'effectuer un rollback de la migration pour replacer le projet à son emplacement d'origine dans la hiérarchie, si nécessaire.
Scénarios de migration
L'emplacement de votre projet détermine le chemin à suivre :
- Migrez des projets d'une organisation vers une autre ressource d'organisation.
- Migrez un projet autonome (créé sans organisation) dans la hiérarchie d'une ressource d'organisation.
Identifier l'état actuel du projet
Avant de commencer, vous devez déterminer si votre projet est associé à une ressource Organisation. Cela détermine si vous suivez le chemin Organisation à organisation ou 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 describe PROJECT_ID
Remplacez PROJECT_ID par l'ID du projet que vous souhaitez migrer.
Si le résultat inclut un champ parent, cela signifie que votre projet fait déjà partie d'une hiérarchie d'organisation.
Si le champ parent 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 correspondant :
- Si vous souhaitez migrer des projets qui ont été 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 ressource d'organisation vers une autre, 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 machines virtuelles (VM) restent actifs et ne subissent aucun temps d'arrêt. La migration met à jour la ressource parente du projet. Comme Google Cloud suit un modèle d'héritage hiérarchique, la posture de sécurité du projet change dès qu'il est associé à un nouveau parent.
| Fonctionnalité | État | Impact |
|---|---|---|
| ID et numéro du projet | Reste identique | Les clés API, les noms de service et les ID codés en dur restent inchangés. |
| Données et ressources | Reste identique | Les VM, les buckets de stockage et les bases de données restent en ligne. |
| Rôles IAM directs | Reste identique | Les rôles attribués directement au projet sont déplacés avec lui. |
| Rôles IAM hérités | Modifications | Les rôles accordés au niveau de l'organisation ou du dossier source sont perdus. |
| Règles d'administration | Modifications | Les contraintes de source sont remplacées par des 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 | Reste identique | Le projet reste associé au compte de facturation d'origine. |
Impact sur le quota
Si vous avez défini des quotas à un certain niveau de ressource, les aspects suivants s'appliquent 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 hérités.
Les pages suivantes peuvent être utilisées pour 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'
...
Remarques importantes
Avant de lancer 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, il est possible que votre projet dépasse son quota à son arrivée.
VPC partagé : vous ne pouvez pas migrer un projet associé à un VPC partagé. Vous devez dissocier le projet du VPC partagé source avant de le déplacer.
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 les déplacer.
Feuille de route de la migration
Utilisez la feuille de route suivante pour parcourir le processus de migration de projet :
- Préparation : créez un plan de migration pour coordonner le calendrier.
- Effectuer : attribuez des rôles IAM et configurez des règles d'administration, puis exécutez la migration.
- Vérifiez : effectuez les tâches post-migration, comme auditer les règles héritées et mettre à jour la facturation.