La migration d'un Google Cloud projet est une opération de métadonnées qui modifie l'emplacement du projet dans la hiérarchie des ressources. Cette page explique le fonctionnement des migrations, ce qui reste identique et ce qui change lorsqu'un projet est déplacé vers une nouvelle organisation.
Projets dans la hiérarchie des ressources
La ressource Projet constitue l'entité d'organisation de base dans une Google Cloud ressource Organisation. Les projets sont créés dans des ressources Organisation et peuvent être placés dans des dossiers ou dans la ressource Organisation elle-même, formant la hiérarchie des ressources.
Vous devrez peut-être migrer des projets entre des ressources 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'annuler une migration et de 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 :
- Migrer des projets d'une organisation vers une autre ressource Organisation.
- Migrer un projet autonome (créé sans organisation) dans la hiérarchie d'une ressource Organisation.
Si vous devez replacer un projet dans Aucune organisation après l'avoir associé à une ressource Organisation, vous devez contacter Cloud Customer Care. L'annulation en libre-service d'une organisation vers aucune organisation n'est pas prise en charge.
En plus de l'API, vous pouvez également utiliser la Google Cloud console pour déplacer des projets en sélectionnant le projet et en lui attribuant une nouvelle destination parent.
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 D'une organisation à une autre ou le chemin Aucune organisation.
Si vous ne disposez pas de l'autorisation resourcemanager.organizations.get sur la
ressource Organisation parente du projet, il est probable que vos projets
ne s'affichent pas comme prévu sous l'organisation réelle dans la
Google Cloud console. Cela peut donner l'impression que le projet n'est associé à aucune ressource Organisation.
Pour déterminer si le projet est associé à une ressource 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 la sortie 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 Organisation.
En fonction de l'état de votre projet, suivez le guide approprié :
- 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 Organisation.
- Si vous souhaitez migrer des projets d'une organisation vers une autre ressource Organisation, consultez Migrer des projets entre des ressources Organisation.
Fonctionnement de la migration
Une migration de 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 aucune interruption. La migration met plutôt à 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 que il est associé à un nouveau parent.
| Fonctionnalité | État | Impact |
|---|---|---|
| ID du projet et numéro | 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 Storage et les bases de données restent en ligne. |
| Rôles IAM directs | Reste identique | Les rôles accordés directement sur le 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 sources sont remplacées par des contraintes de destination. |
| Quotas | Modifications | Les quotas hérités au niveau de l'organisation sont perdus. 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 les quotas
Si vous avez défini des quotas à un certain niveau de ressource, les aspects suivants sont appliqués après la migration :
- Tous les quotas définis au niveau du projet restent inchangés.
- Tous les quotas définis au niveau de la ressource Organisation ne sont pas transférés. L'organisation perd tous les quotas hérités ou les remplacements de quotas.
Les pages suivantes peuvent être utilisées pour déterminer les quotas appliqués à une ressource 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 à son arrivée.
Inventaire des éléments : la propagation complète de la liste 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 du programme de remise Enterprise, ces remises ne s'appliquent pas dans 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 nouvel achat.
Niveaux d'assistance : si aucun contrat d'assistance actif ou niveau d'assistance inférieur n'est disponible 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 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.
- Exécution : attribuez des rôles IAM, configurez des règles d'administration et exécutez la migration.
- Vérification : effectuez des tâches post-migration, telles que l'audit des règles héritées et la mise à jour de la facturation.