Migrer des projets vers une autre organisation

Les ressources de projet Google Cloud Platform (GCP) ne peuvent être migrées dans une organisation que si elles ne sont pas actuellement associées à une organisation. Ce guide explique comment utiliser le service d'assistance Google pour migrer les projets associés à une organisation vers une autre organisation.

Ce guide suppose que l'organisation de destination ressemble de près à l'organisation source. Des efforts de conception plus importants, permettant d'intégrer des applications dans un nouvel écosystème, ne sont pas abordés dans ce guide.

Planifier et effectuer la migration

Étape 1 : Préparer les projets

La migration d'un projet d'une organisation à une autre est un processus d'assistance manuel qui nécessite la configuration de ce projet.

Utilisez la liste suivante pour préparer la migration de votre ressource de projet :

  • Si vous avez modifié le domaine principal du compte Google de votre organisation, incluez ces informations lorsque vous ouvrez une demande auprès de l'assistance Google.
  • Désactivez le réseau VPC partagé pour le projet à déplacer.
  • Configurez tous les rôles Cloud Identity and Access Management personnalisés au niveau de l'organisation dont vous avez besoin au niveau du projet à déplacer. Pour en savoir plus, consultez la section Rôles Cloud IAM personnalisés.
  • Définissez toutes les règles d'administration pour qu'elles héritent de la ressource parente et examinez-les à l'avance afin de comprendre leur effet après la migration. Pour en savoir plus, consultez la section Règles d'administration ci-dessous.
  • Définissez le routage des e-mails pour le domaine principal associé à l'organisation de destination afin de pouvoir accepter la propriété de la nouvelle ressource de projet.
  • Attribuez les rôles Cloud IAM dont vous aurez besoin pour la ressource "Organisation" de destination, par exemple roles/resourcemanager.projectCreator. Tous les rôles hérités seront supprimés après la migration du projet vers l'organisation cible.
  • Si vous utilisez le partage restreint de domaine dans l'organisation cible, ajoutez les domaines ayant accès aux ressources de l'organisation source à la liste blanche de l'organisation cible.

Étape 2 : Ouvrir une demande d'assistance

Si vous disposez d'un plan de services qui inclut les services professionnels Google (PSO), vous devez collaborer pour planifier votre migration de projet. Un responsable de compte technique Google (TAM) peut coordonner les parties concernées côté Google.

Pour démarrer le processus de migration, ouvrez une demande d'assistance et indiquez les éléments suivants :

  1. La liste des ID de projet pour chaque ressource de projet à déplacer.
  2. Si vous collaborez avec PSO pour votre plan de migration, indiquez une date et une heure pour organiser une réunion avec l'assistance Google et PSO via Hangouts. Le TAM organisera la réunion permettant de finaliser votre plan.

L'assistance Google supprime de leur organisation actuelle les ressources de projet que vous avez répertoriées et vous avertit lorsque cette opération est terminée. Vous pouvez ensuite effectuer la migration.

Étape 3 : Effectuer la migration

Pour effectuer la migration, procédez comme suit :

  1. Déplacez les projets dans la nouvelle organisation une fois que Google a fini de les supprimer de l'organisation parente.
  2. Mettez à jour la configuration de service pour vos projets en fonction de la hiérarchie de la nouvelle organisation. Pour en savoir plus, consultez les sections relatives aux services ci-dessous.

Atténuer les problèmes liés aux services

Les ressources de projet GCP constituent la base de l'utilisation de tous les services GCP. Les ressources de projet s'appuient sur la ressource "Organisation" pour de nombreuses fonctions. Ce fonctionnement peut être perturbé lorsque vous déplacez une ressource de projet d'une organisation à une autre. Vous devez planifier des stratégies d'atténuation pour chacun des services utilisés par les ressources de projet que vous déplacez.

Rôles Cloud IAM personnalisés

Des rôles Cloud IAM personnalisés peuvent être créés au niveau de l'organisation dans la hiérarchie des ressources GCP. Ceux-ci permettent d'accorder un accès aux utilisateurs situés sous la ressource "Organisation" dans la hiérarchie. Lorsqu'un projet est retiré de l'organisation, les rôles personnalisés configurés au niveau de l'organisation ne sont pas déplacés en même temps que celui-ci, mais les rôles personnalisés configurés au niveau du projet le sont.

Les rôles personnalisés au niveau de l'organisation qui ne sont pas déplacés ne fonctionnent plus, et la méthode getIamPolicy ne renvoie pas ces rôles personnalisés dans le cadre de la stratégie IAM Cloud.

Lorsque vous déplacez un projet présentant des rôles personnalisés, certaines des règles d'administration d'origine peuvent toujours affecter le projet. Si un rôle personnalisé provenant de l'ancienne organisation existe dans la nouvelle stratégie IAM Cloud, il est possible que cette stratégie soit invalidée et que des erreurs se produisent lorsque vous essayez de la mettre à jour. Il est peu probable que ce problème se présente immédiatement après la migration, car il ne se produit que lorsque vous essayez de mettre à jour la stratégie IAM Cloud.

Pour répertorier les rôles personnalisés existants au niveau de l'organisation, procédez comme suit :

gcloud iam roles list --organization ORGANIZATION_ID

Pour décrire un rôle personnalisé particulier dans une organisation, procédez comme suit :

gcloud iam roles describe --organization ORGANIZATION_ID /
ROLE_NAME

Où :

Atténuation des risques

Pour réduire le risque d'erreurs relatives aux rôles Cloud IAM personnalisés existants, procédez comme suit :

  1. Utilisez la méthode projects.getIamPolicy pour obtenir la stratégie IAM Cloud du projet que vous souhaitez déplacer.
  2. Pour chaque rôle personnalisé au niveau de l'organisation dans la stratégie IAM Cloud de projet, créez un rôle personnalisé équivalent au niveau du projet et mettez à jour la stratégie IAM Cloud de projet pour qu'elle utilise ces nouveaux rôles.
    1. Si vous devez augmenter votre quota de projet, envoyez une demande d'augmentation de celui-ci.
  3. Supprimez les liaisons des rôles personnalisés Cloud IAM au niveau de l'organisation pour les projets à déplacer.
  4. Effectuez la migration des projets comme indiqué ci-dessus.
  5. Mettez à jour les stratégies Cloud IAM des ressources dans les projets déplacés pour qu'elles utilisent les rôles personnalisés de l'organisation cible.

Pour en savoir plus, consultez la page Créer et gérer les rôles personnalisés.

VPC partagés

Les VPC partagés dans GCP utilisent la ressource "Organisation" pour le regroupement. Les ressources de projet ne peuvent être connectées qu'à des VPC partagés au sein de la même organisation. Un projet déplacé dans une nouvelle organisation ne conserve pas la connexion VPC partagée.

Les VPC partagés sont mis en œuvre à l'aide d'un projet hôte dans lequel le VPC partagé est provisionné, et les projets de service sont autorisés à utiliser les VPC partagés.

Les machines virtuelles Compute Engine (VM) ne peuvent pas être directement déplacées d'un VPC à un autre, et doivent être migrées ou recréées. Les VM sont généralement provisionnées dans les projets de service de VPC partagé, et non directement dans le projet hôte de VPC partagé.

Pour répertorier tous les projets hôtes de VPC partagé dans une ressource "Organisation", procédez comme suit :

gcloud beta compute shared-vpc organizations list-host-projects
ORGANIZATION_ID

ORGANIZATION_ID correspond à l'ID de l'organisation.

Atténuation des risques

  1. Accédez à la page VPC partagé de la console GCP.
    Accéder à la page "VPC partagé"
  2. Dressez la liste des projets hôtes, des réseaux VPC partagés et de tous les projets de service associés qui s'affichent sur la page VPC partagé.
    1. Si vous migrez tous les projets d'une organisation, répertoriez tous les projets hôtes de VPC partagé à l'aide de la commande list-host-projects ci-dessus.
  3. Provisionnez des projets hôtes équivalents et des VPC partagés dans la nouvelle organisation. Pour obtenir des instructions détaillées, consultez la section Configurer le VPC partagé.
  4. Supprimez les projets à déplacer des VPC partagés dans l'organisation source de la façon suivante :
    1. Réalisez des instantanés des disques de VM connectés au VPC partagé.
    2. Arrêtez les VM connectées au VPC partagé.
    3. Supprimez les VM.
    4. Supprimez tous les équilibreurs de charge internes connectés au VPC partagé.
  5. Restaurez les VM à partir des instantanés et connectez-vous à un VPC de portée locale dans le projet de service.
  6. Effectuez la migration.
  7. Connectez vos projets déplacés aux nouveaux VPC partagés.

Appairage de VPC

Les projets utilisant l'appairage de VPC Google peuvent être déplacés d'une organisation à une autre, car l'appairage ne dépend pas de l'appartenance à une organisation pour fonctionner. Cela signifie que lorsque l'appairage VPC est activé lors du transfert d'un projet dans une organisation, l'appairage est activé pour ce projet.

Atténuation des risques

Si vous déplacez un projet dans une organisation dans laquelle l'appairage VPC est activé, identifiez l'autre extrémité de l'appairage avant la migration et vérifiez que vous souhaitez bien que l'appairage VPC du projet soit activé.

Cloud Interconnect

Les projets contenant une interconnexion dédiée ne peuvent être déplacés vers une nouvelle organisation que si aucun rattachement de VLAN n'est défini pour Cloud Interconnect.

Atténuation des risques

Supprimez tout rattachement de VLAN des projets à déplacer avant la migration.

Renommage de domaine

Si l'organisation source a déjà subi un changement de nom de domaine, des étapes supplémentaires peuvent être nécessaires de la part de Google pour migrer des projets hors de cette organisation.

Atténuation des risques

Lorsque vous ouvrez une demande d'assistance pour migrer vos projets, fournissez les détails de l'opération de changement de domaine, y compris les ancien et nouveau noms de domaine. Google dispose d'outils permettant de gérer ce scénario, mais la migration peut nécessiter un délai supplémentaire.

Règles d'administration

Le déplacement d'un projet dans une nouvelle organisation peut modifier les stratégies appliquées à ce projet en fonction de l'héritage. Les stratégies de l'organisation source peuvent différer de celles de l'organisation de destination, et la règle d'administration en vigueur peut avoir une incidence différente sur votre projet après la migration.

Atténuation des risques

Pour chaque projet à transférer, définissez la règle d'administration à hériter de la ressource parente. Vous devez examiner les règles à l'avance afin de pouvoir planifier la création d'un nouvel ensemble de règles d'administration qui contiendra la règle en vigueur que vous souhaitez pour la nouvelle organisation.

Pour en savoir plus sur l'héritage des règles d'administration, consultez la page Comprendre le processus d'évaluation hiérarchique.

Cloud Billing

Les comptes Cloud Billing peuvent être utilisés dans toutes les organisations. Le déplacement d'un projet d'une organisation à une autre n'aura pas d'incidence sur la facturation, et les frais continueront à être imputés à l'ancien compte de facturation. Toutefois, les changements d'organisation incluent souvent également l'obligation de passer à un nouveau compte de facturation.

Modifier le compte de facturation d'un projet

Pour modifier le compte de facturation d'un projet existant, vous devez disposer du rôle roles/owner pour ce projet et du rôle roles/billing.admin pour le compte de facturation de destination. Pour modifier le compte de facturation, procédez comme suit :

  1. Accédez à la page Facturation dans la console GCP :
    Accéder à la page "Facturation"
  2. Cliquez sur le nom du compte de facturation que vous souhaitez modifier.
  3. Dans la section Projets associés à ce compte de facturation, recherchez le nom du projet à déplacer, puis cliquez sur le bouton de menu situé sur la droite.
  4. Cliquez sur Modifier la facturation, puis sélectionnez le nouveau compte de facturation.
  5. Cliquez sur Définir le compte.

Les frais dont vous êtes déjà redevable et qui ne sont pas encore inclus dans l'historique des transactions seront facturés sur l'ancien compte de facturation. Ces frais peuvent correspondre à des opérations effectuées dans les deux jours qui précèdent le transfert du projet.

Déplacer un compte de facturation d'une organisation à une autre

Un compte de facturation peut être déplacé d'une organisation à une autre, bien que cette étape ne soit souvent pas nécessaire. La plupart des organisations existantes comportent déjà un compte de facturation qui doit être utilisé à la place. Si vous devez migrer un compte de facturation existant, procédez comme suit :

  1. Obtenez les autorisations nécessaires à la migration :
    1. role/resourcemanager.organizationAdmin pour l'organisation source.
    2. roles/billing.admin pour l'organisation source ou pour les comptes de facturation spécifiques à déplacer.
    3. role/resourcemanager.organizationAdmin pour l'organisation de destination.
    4. roles/billing.admin ou roles/billing.creator pour l'organisation de destination.
  2. Accédez à la page Facturation dans la console GCP :
    Accéder à la page "Facturation"
  3. Cliquez sur le nom du compte de facturation que vous souhaitez déplacer.
  4. En haut de la page Présentation, cliquez sur Modifier l'organisation.
  5. Sélectionnez l'organisation de destination, puis cliquez sur OK.

Le compte de facturation est maintenant associé à l'organisation spécifiée.

Cette page vous a-t-elle été utile ? Évaluez-la :

Envoyer des commentaires concernant…

Documentation relative à Resource Manager