Migrer depuis AWS vers Google Cloud : migrer depuis Amazon EC2 vers Compute Engine

Last reviewed 2024-11-20 UTC

Google Cloud fournit des outils, des produits, des conseils et des services professionnels pour migrer des machines virtuelles (VM) avec leurs données depuis Amazon Elastic Compute Cloud (Amazon EC2) vers Compute Engine. Ce document explique comment concevoir, mettre en œuvre et valider un plan de migration depuis Amazon EC2 vers Compute Engine.

Ce document est destiné aux administrateurs cloud qui souhaitent en savoir plus sur la planification et la mise en œuvre d'un processus de migration. Il s'adresse également aux décisionnaires qui évaluent l'opportunité d'effectuer une migration et qui souhaitent découvrir en quoi elle pourrait consister.

Ce document fait partie d'une série d'articles sur la migration depuis AWS vers Google Cloud, qui comprend les documents suivants :

Pour cette migration vers Google Cloud, nous vous recommandons de suivre le framework de migration décrit dans la section Migrer vers Google Cloud : premiers pas.

Le diagramme suivant illustre le parcours de votre migration.

Chemin de migration en quatre phases.

Vous pouvez migrer depuis votre environnement source vers Google Cloud dans une série d'itérations. Par exemple, vous pouvez commencer par migrer certaines charges de travail, et en migrer d'autres ultérieurement. Pour chaque itération de migration distincte, vous suivez les phases du framework de migration général :

  1. Évaluer et découvrir vos charges de travail et vos données
  2. Planifier et établir vos fondations sur Google Cloud
  3. Migrer vos charges de travail et vos données vers Google Cloud
  4. Optimiser votre environnement Google Cloud

Pour en savoir plus sur les phases de ce framework, consultez la page Migrer vers Google Cloud : premiers pas.

Pour concevoir un plan de migration efficace, nous vous recommandons de valider chaque étape du plan et de vous assurer de disposer d'une stratégie de rollback. Pour vous aider à valider votre plan de migration, consultez la page Migrer vers Google Cloud : bonnes pratiques pour valider un plan de migration.

Évaluer l'environnement source

Au cours de la phase d'évaluation, vous déterminez les exigences et les dépendances pour migrer votre environnement source vers Google Cloud.

La phase d’évaluation est cruciale pour la réussite de votre migration. Vous devez acquérir une connaissance approfondie des charges de travail que vous souhaitez migrer, de leurs exigences, de leurs dépendances et de votre environnement actuel. Vous devez comprendre votre point de départ pour planifier et exécuter avec succès une migration Google Cloud.

La phase d'évaluation comprend les tâches suivantes :

  1. Dresser un inventaire complet de vos applications
  2. Cataloguer vos charges de travail en fonction de leurs propriétés et de leurs dépendances
  3. Former et préparer vos équipes sur Google Cloud
  4. Créer des tests et des démonstrations de faisabilité sur Google Cloud
  5. Calculer le coût total de possession (TCO) de l'environnement cible
  6. Choisissez la stratégie de migration pour vos charges de travail.
  7. Choisissez vos outils de migration.
  8. Définissez le plan de migration et le calendrier.
  9. Validez votre plan de migration.

Pour en savoir plus sur la phase d'évaluation et ces tâches, consultez la page Migrer vers Google Cloud : évaluer et découvrir vos charges de travail. Les sections suivantes sont basées sur les informations de ce document.

Dresser l'inventaire de vos instances Amazon EC2

Pour couvrir votre migration, vous devez créer un inventaire de vos instances Amazon EC2. Vous pouvez ensuite utiliser l'inventaire pour évaluer vos processus de déploiement et opérationnels pour le déploiement de charges de travail sur ces instances.

Pour créer l'inventaire de vos instances Amazon EC2, nous vous recommandons d'utiliser le Centre de migration, la plate-forme unifiée de Google Cloud qui vous aide à accélérer votre transition cloud de bout en bout, de votre environnement actuel vers Google Cloud. Migration Center vous permet d'importer des données depuis Amazon EC2 et d'autres ressources AWS. Migration Center recommande ensuite des services Google Cloud pertinents vers lesquels migrer.

Après avoir évalué votre environnement à l'aide du centre de migration, nous vous recommandons de générer un rapport d'évaluation technique de la migration à l'aide de la CLI du client de découverte du centre de migration. Pour en savoir plus, consultez la page Collecter les données des invités à partir d'instances Amazon EC2 pour l'évaluation de l'adéquation hors connexion.

Les données fournies par le centre de migration et la CLI du client de découverte du centre de migration ne capturent peut-être pas complètement les dimensions qui vous intéressent. Dans ce cas, vous pouvez intégrer ces données aux résultats d'autres mécanismes de collecte de données que vous créez et qui sont basés sur les API AWS, les outils de développement AWS et l'interface de ligne de commande AWS.

En plus des données obtenues à partir du centre de migration et de la CLI du client de détection du centre de migration, tenez compte des points de données suivants pour chaque instance Amazon EC2 que vous souhaitez migrer :

  • La région et la zone de déploiement
  • Le type et la taille de l'instance
  • L'image AMI (Amazon Machine Image) à partir de laquelle l'instance est lancée
  • Le nom d'hôte de l'instance, et la manière dont les autres instances et charges de travail utilisent ce nom d'hôte pour communiquer avec l'instance
  • Les tags d'instance, ainsi que les métadonnées et les données utilisateur
  • Le type de virtualisation d'instance
  • L'option d'achat d'instance, telle que l'achat à la demande ou l'achat au comptant
  • Comment l'instance stocke-t-elle les données, par exemple à l'aide de data stores d'instance et de volumes Amazon EBS ?
  • La configuration de la location d'instances
  • Si l'instance se trouve dans un groupe d'emplacements spécifique
  • Si l'instance se trouve dans un groupe d'autoscaling spécifique
  • Les groupes de sécurité auxquels l'instance appartient
  • Toute configuration de pare-feu réseau AWS impliquant l'instance.
  • Si les charges de travail qui s'exécutent sur l'instance sont protégées par AWS Shield et AWS WAF
  • Si vous contrôlez l'état du processeur de votre instance et la manière dont les charges de travail qui s'exécutent sur l'instance dépendent de l'état du processeur
  • La configuration du programmeur d'E/S de l'instance
  • La manière dont vous exposez des charges de travail exécutées sur l'instance à des clients exécutés dans votre environnement AWS (comme d'autres charges de travail) et à des clients externes

Évaluer vos processus de déploiement et opérationnels

Il est essentiel de bien comprendre leur fonctionnement. Ces processus font partie intégrante des pratiques qui préparent et gèrent votre environnement de production et les charges de travail qui y sont exécutées.

Vos processus de déploiement et opérationnels peuvent créer les artefacts dont vos charges de travail ont besoin pour fonctionner. Par conséquent, vous devez collecter des informations sur chaque type d'artefact. Par exemple, un artefact peut être un package du système d'exploitation, un package de déploiement d'application, une image du système d'exploitation, une image de conteneur ou autre.

Outre le type d'artefact, réfléchissez à la façon dont vous effectuez les tâches suivantes :

  • Développez vos charges de travail. Évaluez les processus mis en place par les équipes de développement pour créer vos charges de travail. Par exemple, comment vos équipes de développement conçoivent-elles, codent-elles et testent-elles vos charges de travail ?
  • Générez les artefacts que vous déployez dans votre environnement source. Pour déployer vos charges de travail dans votre environnement source, vous pouvez générer des artefacts déployables, tels que des images de conteneur ou des images de système d'exploitation, ou vous pouvez personnaliser des artefacts existants, tels que des images de système d'exploitation tiers en installant et en configurant des logiciels. La collecte d'informations sur la manière dont vous générez ces artefacts vous permet de vous assurer qu'ils sont adaptés au déploiement dans Google Cloud.

  • Stockez les artefacts. Si vous produisez des artefacts que vous stockez dans un registre d'artefacts dans votre environnement source, vous devez les rendre disponibles dans votre environnement Google Cloud. Pour ce faire, vous pouvez utiliser des stratégies telles que les suivantes :

    • Établir un canal de communication entre les environnements : rendez les artefacts de votre environnement source accessibles depuis l'environnement Google Cloud cible.
    • Refactoriser le processus de compilation des artefacts : effectuez une refactorisation mineure de votre environnement source afin de pouvoir stocker des artefacts à la fois dans l'environnement source et dans l'environnement cible. Cette approche traite votre migration en créant une infrastructure telle qu'un dépôt d'artefacts avant que vous ayez à implémenter des processus de compilation d'artefacts dans l'environnement Google Cloud cible. Vous pouvez mettre en œuvre cette approche directement ou vous appuyer sur l'approche précédente qui consiste à d'abord établir un canal de communication.

    Le fait de disposer d'artefacts disponibles dans les environnements source et cible vous permet de vous concentrer sur la migration sans avoir à implémenter de processus de compilation d'artefacts dans l'environnement Google Cloud cible dans le cadre de la migration.

  • Scanner et signer le code. Dans le cadre de vos processus de compilation d'artefacts, vous pouvez utiliser l'analyse de code pour vous protéger contre les failles courantes et l'exposition involontaire au réseau, et la signature de code pour vous assurer que seul le code approuvé s'exécute dans vos environnements.

  • Déployez des artefacts dans votre environnement source. Après avoir généré des artefacts déployables, vous pouvez les déployer dans votre environnement source. Nous vous recommandons d'évaluer chaque processus de déploiement. L'évaluation permet de s'assurer que vos processus de déploiement sont compatibles avec Google Cloud. Elle vous permet également de comprendre les efforts nécessaires pour refactoriser les processus à terme. Par exemple, si vos processus de déploiement ne fonctionnent qu'avec votre environnement source, vous devrez peut-être les refactoriser pour cibler votre environnement Google Cloud.

  • L'injection d'une configuration d'exécution. Vous pouvez injecter une configuration d'environnement d'exécution pour des clusters, des environnements d'exécution ou des déploiements de charges de travail spécifiques. La configuration peut initialiser des variables d'environnement et d'autres valeurs de configuration telles que des secrets, des identifiants et des clés. Pour vous assurer que vos processus d'injection de configuration d'environnement d'exécution fonctionnent sur Google Cloud, nous vous recommandons d'évaluer la façon dont vous configurez les charges de travail exécutées dans votre environnement source.

  • Journalisation, surveillance et profilage Évaluez les processus de journalisation, de surveillance et de profilage que vous avez mis en place pour surveiller l'état de votre environnement source, les métriques d'intérêt et la façon dont vous consommez les données fournies par ces processus.

  • Authentification Évaluez la façon dont vous vous authentifiez auprès de votre environnement source.

  • Provisionnez et configurez vos ressources. Pour préparer votre environnement source, vous avez peut-être conçu et implémenté des processus de provisionnement et de configuration des ressources. Par exemple, vous pouvez utiliser Terraform avec des outils de gestion de la configuration pour provisionner et configurer des ressources dans votre environnement source.

Planifier et établir vos fondations

Au cours de la phase de planification et de compilation, vous provisionnez et configurez l'infrastructure pour effectuer les opérations suivantes :

  • Exécuter vos charges de travail dans votre environnement Google Cloud
  • Se connecter à votre environnement source et à votre environnement Google Cloud pour effectuer la migration

La phase de planification et de compilation est composée des tâches suivantes :

  1. Créez une hiérarchie de ressources.
  2. Configurer Identity and Access Management (IAM) de Google Cloud
  3. Configurer la facturation
  4. Configurez la connectivité réseau.
  5. Renforcez votre sécurité.
  6. Configurer la journalisation, la surveillance et les alertes

Pour en savoir plus sur chacune de ces tâches, consultez la section Migrer vers Google Cloud: planifier et créer vos fondations.

Migrez vos charges de travail

Pour migrer vos charges de travail depuis Amazon EC2 vers Compute Engine, procédez comme suit :

  1. Migrez des VM depuis Amazon EC2 vers Compute Engine.
  2. Migrez les disques de votre VM vers Persistent Disk.
  3. Exposez des charges de travail exécutées sur Compute Engine à des clients.
  4. Refactorisez les processus de déploiement et opérationnels pour cibler Google Cloud au lieu de cibler Amazon EC2.

Les sections suivantes fournissent des détails sur chacune de ces tâches.

Migrer vos VM vers Compute Engine

Pour migrer des VM depuis Amazon EC2 vers Compute Engine, nous vous recommandons d'utiliser Migrate to Virtual Machines, qui est un service entièrement géré. Pour en savoir plus, consultez la page Parcours de migration avec Migrate to VMs.

Dans le cadre de la migration, Migrate for VMs migre les instances Amazon EC2 dans leur état actuel, à l'exception des modifications de configuration requises. Si vos instances Amazon EC2 exécutent des AMI Amazon EC2 personnalisées, Migrate to Virtual Machines migre ces personnalisations vers des instances Compute Engine. Toutefois, si vous souhaitez rendre votre infrastructure reproductible, vous devrez peut-être appliquer des personnalisations équivalentes en créant des images de système d'exploitation Compute Engine dans le cadre de vos processus de déploiement et opérationnels, comme expliqué plus loin dans ce document. Vous pouvez également importer vos AMI Amazon EC2 dans Compute Engine.

Migrer les disques de vos VM vers Persistent Disk

Vous pouvez également utiliser Migrate to VMs pour migrer des disques depuis vos VM Amazon EC2 sources vers Persistent Disk, avec un minimum d'interruptions dans les charges de travail exécutées sur les VM Amazon EC2. Pour en savoir plus, consultez la section Migrer des disques de VM et les associer à une nouvelle VM.

Par exemple, vous pouvez migrer un disque de données associé à une VM Amazon EC2 vers un disque persistant, puis l'associer à une nouvelle VM Compute Engine.

Exposer des charges de travail exécutées sur Compute Engine

Une fois que vous avez migré vos instances Amazon EC2 vers des instances Compute Engine, vous devrez peut-être provisionner et configurer votre environnement Google Cloud pour exposer les charges de travail aux clients.

Google Cloud propose des services et des produits sécurisés et fiables permettant d'exposer vos charges de travail aux clients. Pour les charges de travail exécutées sur vos instances Compute Engine, vous devez configurer des ressources pour les catégories suivantes :

  • Pare-feu
  • Équilibrage de charge du trafic
  • Noms, zones et enregistrements DNS
  • Protection contre les attaques DDoS et pare-feu d'application Web

Pour chacune de ces catégories, vous pouvez commencer par mettre en œuvre une configuration de référence semblable à la configuration des services et ressources AWS dans la catégorie équivalente. Vous pouvez ensuite itérer sur la configuration et utiliser les fonctionnalités supplémentaires fournies par les services Google Cloud.

Les sections suivantes expliquent comment provisionner et configurer des ressources Google Cloud dans ces catégories, et comment elles sont mappées aux ressources AWS dans des catégories équivalentes.

Pare-feu

Si vous avez configuré des groupes de sécurité AWS et des stratégies et des règles de pare-feu de réseau AWS, vous pouvez configurer des stratégies et des règles de pare-feu cloud nouvelle génération. Vous pouvez également provisionner des règles VPC Service Controls pour réguler le trafic réseau au sein de votre VPC. Vous pouvez utiliser VPC Service Controls pour bloquer les connexions réseau indésirables à vos instances Compute Engine et pour limiter le risque d'exfiltration de données.

Par exemple, si vous utilisez des groupes de sécurité AWS pour autoriser ou refuser les connexions à vos instances Amazon EC2, vous pouvez configurer des règles de pare-feu de cloud privé virtuel (VPC) équivalentes qui s'appliquent à vos instances Compute Engine.

Équilibrage de charge du trafic

Si vous avez configuré Elastic Load Balancing (ELB) dans votre environnement AWS, vous pouvez configurer Cloud Load Balancing pour répartir le trafic réseau afin d'améliorer l'évolutivité de vos charges de travail dans Google Cloud. Cloud Load Balancing est compatible avec plusieurs produits d'équilibrage de charge mondiaux et régionaux qui fonctionnent sur différentes couches du modèle OSI, comme au niveau de la couche de transport et de la couche d'application. Vous pouvez choisir un produit d'équilibrage de charge adapté aux exigences de vos charges de travail.

Cloud Load Balancing permet également de configurer le protocole TLS (Transport Layer Security) pour chiffrer le trafic réseau. Lorsque vous configurez TLS pour Cloud Load Balancing, vous pouvez utiliser des certificats TLS autogérés ou gérés par Google en fonction de vos besoins.

Noms, zones et enregistrements DNS

Si vous utilisez Amazon Route 53 dans votre environnement AWS, vous pouvez utiliser les éléments suivants dans Google Cloud :

Par exemple, si vous avez enregistré un domaine à l'aide d'Amazon Route 53, vous pouvez le transférer vers Cloud Domains. De même, si vous avez configuré des zones DNS publiques et privées à l'aide d'Amazon Route 53, vous pouvez migrer cette configuration vers Cloud DNS.

Protection contre les attaques DDoS et pare-feu d'application Web

Si vous avez configuré AWS Shield et AWS WAF dans votre environnement AWS, vous pouvez utiliser Google Cloud Armor pour protéger vos charges de travail Google Cloud contre les attaques DDoS et les exploits courants.

Refactoriser les processus de déploiement et opérationnels

Après avoir refactorisé vos charges de travail, vous devez refactoriser vos processus de déploiement et d'exploitation pour effectuer les opérations suivantes:

  • Provisionnez et configurez des ressources dans votre environnement Google Cloud au lieu de le faire dans votre environnement source.
  • Créez et configurez des charges de travail, puis déployez-les dans Google Cloud au lieu de les déployer dans votre environnement source.

Vous avez recueilli des informations sur ces processus lors de la phase d'évaluation plus tôt dans ce processus.

Le type de refactoring que vous devez envisager pour ces processus dépend de la façon dont vous les avez conçus et implémentés. La refactorisation dépend également de l'état final que vous souhaitez pour chaque processus. Nous vous conseillons, par exemple, de suivre les recommandations suivantes :

  • Vous avez peut-être mis en œuvre ces processus dans votre environnement source, et vous avez l'intention de concevoir et de mettre en œuvre des processus équivalents dans Google Cloud. Par exemple, vous pouvez refactoriser ces processus pour utiliser Cloud Build, Cloud Deploy et Infrastructure Manager.
  • Vous avez peut-être implémenté ces processus dans un autre environnement tiers en dehors de votre environnement source. Dans ce cas, vous devez refactoriser ces processus pour cibler votre environnement Google Cloud au lieu de votre environnement source.
  • Une combinaison des approches précédentes.

La refactorisation des processus de déploiement et opérationnels peut être complexe et nécessiter un effort considérable. Si vous essayez d'effectuer ces tâches lors de la migration de votre charge de travail, celle-ci peut devenir plus complexe et vous exposer à des risques. Après avoir évalué vos processus de déploiement et opérationnels, vous comprenez probablement leur conception et leur complexité. Si vous estimez que vous avez besoin d'un effort considérable pour refactoriser vos processus de déploiement et opérationnels, nous vous recommandons de refactoriser ces processus au cours d'un projet distinct dédié.

Pour en savoir plus sur la conception et la mise en œuvre des processus de déploiement sur Google Cloud, consultez les ressources suivantes:

Ce document se concentre sur les processus de déploiement qui produisent les artefacts à déployer et les déploient dans l'environnement d'exécution cible. La stratégie de refactoring dépend fortement de la complexité de ces processus. La liste suivante décrit une stratégie de refactoring générale possible:

  1. Provisionnez des dépôts d'artefacts sur Google Cloud. Par exemple, vous pouvez utiliser Artifact Registry pour stocker des artefacts et créer des dépendances.
  2. Refactorisez vos processus de compilation pour stocker des artefacts à la fois dans votre environnement source et dans Artifact Registry.
  3. Refactorisez vos processus de déploiement pour déployer vos charges de travail dans votre environnement Google Cloud cible. Par exemple, vous pouvez commencer par déployer un petit sous-ensemble de vos charges de travail dans Google Cloud, à l'aide d'artefacts stockés dans Artifact Registry. Vous augmentez ensuite progressivement le nombre de charges de travail déployées dans Google Cloud, jusqu'à ce que toutes les charges de travail à migrer s'exécutent sur Google Cloud.
  4. Refactorisez vos processus de compilation pour stocker les artefacts dans Artifact Registry uniquement.
  5. Si nécessaire, migrez les versions antérieures des artefacts à déployer depuis les dépôts de votre environnement source vers Artifact Registry. Par exemple, vous pouvez copier des images de conteneur dans Artifact Registry.
  6. Mettez hors service les dépôts de votre environnement source lorsque vous n'en avez plus besoin.

Pour faciliter les éventuels rollbacks en raison de problèmes imprévus lors de la migration, vous pouvez stocker des images de conteneurs à la fois dans vos dépôts d'artefacts actuels dans Google Cloud pendant la migration vers Google Cloud. Enfin, dans le cadre du décommissionnement de votre environnement source, vous pouvez refactoriser vos processus de création d'images de conteneur pour stocker des artefacts uniquement dans Google Cloud.

Bien que cela ne soit pas essentiel à la réussite d'une migration, vous devrez peut-être migrer vos versions antérieures d'artefacts depuis votre environnement source vers vos dépôts d'artefacts sur Google Cloud. Par exemple, pour permettre le rollback de vos charges de travail à des moments arbitraires, vous devrez peut-être migrer les versions antérieures de vos artefacts vers Artifact Registry. Pour en savoir plus, consultez la page Migrer des images à partir d'un registre tiers.

Si vous utilisez Artifact Registry pour stocker vos artefacts, nous vous recommandons de configurer des contrôles pour vous aider à sécuriser vos dépôts d'artefacts, tels que le contrôle des accès, la prévention de l'exfiltration de données, l'analyse des failles et l'autorisation binaire. Pour en savoir plus, consultez la section Contrôler l'accès et protéger les artefacts.

Optimiser votre environnement Google Cloud

L'optimisation est la dernière phase de votre migration. Au cours de cette phase, vous effectuez des itérations sur les tâches d'optimisation jusqu'à ce que votre environnement réponde à vos exigences d'optimisation. Les étapes de chaque itération sont les suivantes :

  1. Évaluer votre environnement actuel, vos équipes et votre boucle d'optimisation
  2. Définir vos exigences et vos objectifs d'optimisation
  3. Optimiser votre environnement et vos équipes
  4. Ajuster la boucle d'optimisation

Vous devez répéter cette séquence jusqu'à ce que vous ayez atteint vos objectifs d'optimisation.

Pour en savoir plus sur l'optimisation de votre environnement Google Cloud, consultez les pages Migrer vers Google Cloud : optimiser votre environnement et Processus d'optimisation des performances.

Étape suivante

Contributeurs

Auteur: Marco Ferrari | Architecte de solutions cloud