Architecture de Migrate to Containers

Cet article décrit en détail comment Migrate to Containers transforme vos applications hébergées sur des VM en conteneurs sur Google Kubernetes Engine (GKE) ou Anthos.

Composants de Migrate to Containers

La solution Migrate to Containers couvre quatre niveaux opérationnels :

  1. Traitement : cluster de traitement GKE ou Anthos permettant d'exécuter les composants Migrate to Containers qui effectuent les transformations requises lors de la migration de la charge de travail d'une VM source vers les artefacts de conteneur cibles.

    Le cluster de traitement peut être un cluster existant ou un cluster configuré séparément pour les activités de migration (recommandé). Le cluster de traitement est l'emplacement où sont installés les composants de Migrate to Containers. Une fois les conteneurs générés et qu'aucune autre migration n'est nécessaire, vous pouvez supprimer le cluster de traitement ou désinstaller la configuration Migrate to Containers.

    • Pour les VM VMware déployées en tant que conteneurs sur Google Cloud, les clusters de traitement peuvent être un cluster GKE ou Anthos sur Google Cloud.

    • Les VM VMware destinées au déploiement en tant que conteneurs sur site nécessitent une solution Anthos sur bare metal.

  2. Contrôle : le CRD de migration, l'utilitaire CLI (migctl) et Google Cloud Console sont les interfaces principales par lesquelles la migration est configurée et exploitée. Ces opérations incluent :

    • Installer/Désinstaller Migrate to Containers sur un cluster de traitement et valider le déploiement

    • Configurer les sources de migration

    • Gérer les actions du workflow de migration

    • Fournir une visibilité de vos migrations, avec leur état, leur progression et leurs journaux.

  3. Déploiement des charges de travail : vous pouvez déployer les charges de travail de conteneurs migrés sur n'importe quel cluster GKE ou Anthos répondant aux exigences minimales. Les artefacts de migration peuvent inclure un ou plusieurs fichiers Dockerfile, une ou plusieurs spécifications de déploiement Kubernetes et un fichier de configuration Skaffold.

  4. Maintenance : après avoir migré vos charges de travail de conteneurs, vous effectuez généralement des opérations d'optimisation et de maintenance. Le contenu de charge de travail extrait et le fichier Dockerfile généré peuvent être intégrés dans un pipeline CI/CD pour une maintenance efficace basée sur des images.

À propos de Migrate to Virtual Machines

Avec Migrate to Containers, vous mettez en conteneur vos applications existantes basées sur des VM de sorte qu'elles s'exécutent sur des clusters Google Kubernetes Engine (GKE) ou Anthos. Pour migrer vers Google Cloud des charges de travail exécutées sur VMware, outre Migrate to Containers, vous devez également configurer Migrate to Virtual Machines.

Vous pouvez choisir l'une des approches décrites dans les sections suivantes pour migrer vos charges de travail VMware vers Google Cloud.

Migrer puis moderniser

Vous pouvez migrer vers des conteneurs en divisant votre parcours de migration en deux phases distinctes, même pour les charges de travail adaptées aux conteneurs :

  1. Migrer des charges de travail vers Compute Engine avec Migrate to Virtual Machines

  2. Migrer de Compute Engine vers des conteneurs avec Migrate to Containers

Cette méthode est utile, par exemple dans le cas où vous souhaitez effectuer une migration de centre de données et migrer toutes les charges de travail vers Compute Engine, et seulement dans un deuxième temps moderniser de manière sélective les charges de travail appropriées vers des conteneurs.

Vous pouvez également utiliser cette approche pour migrer des charges de travail à partir d'autres plates-formes sources, telles qu'AWS et Azure, pour lesquelles la conteneurisation n'est pas compatible avec Migrate to Containers.

Allier migration et modernisation

Vous pouvez combiner Migrate to Virtual Machines à Migrate to Containers pour migrer vos charges de travail vers Google Cloud.