Migrer une VM monolithique – Migration et déploiement

Avec une configuration de cluster de traitement et une installation de Migrate for Anthos and GKE, vous êtes prêt à effectuer la migration. Pour commencer, vous devez ajouter une source de migration pertinente pour votre cluster de traitement, puis générer un plan de migration pour votre VM. Après avoir examiné et personnalisé le plan en fonction de vos besoins, vous pouvez générer et déployer des artefacts Kubernetes sur le cluster GKE qui exécute déjà le reste de votre application.

Objectifs

À la fin de ce tutoriel, vous aurez appris à :

  • ajouter une source de migration ;
  • créer un plan de migration à partir de la charge de travail de votre VM ;
  • examiner et personnaliser le plan de migration ;
  • générer et déployer des artefacts de migration sur votre cluster GKE.

Avant de commencer

Ce tutoriel fait suite au tutoriel Détection et évaluation. Avant de commencer ce tutoriel, suivez les instructions de cette page pour exécuter les outils de découverte sur la VM monolithique et créer votre cluster de traitement.

Arrêter la VM monolithique

Avant d'effectuer une migration, vous devez arrêter la VM monolithique afin d'éviter toute perturbation involontaire ou toute corruption des données pouvant survenir si des données sont en cours de déplacement pendant les processus de migration.

  1. Dans Google Cloud Console, accédez à la page Instances de VM.

    Accéder à la page Instances de VM

  2. Sélectionnez la case située à l'extrémité gauche de la ligne de la VM ledgermonolith-service.

  3. En haut de la page, cliquez sur le bouton Arrêter pour arrêter la VM.

  4. Attendez que la VM soit complètement arrêtée. L'opération peut prendre 1 à 2 minutes.

Migrer la VM

Maintenant que la VM que vous souhaitez migrer est complètement arrêtée, vous pouvez commencer à la préparer et à l'exécuter. Vous devez d'abord créer une source pour désigner votre cluster de traitement en tant que cluster désigné pour votre migration Compute Engine. Vous pouvez ensuite lancer la migration complète de votre VM.

Ajouter une source

  1. Ouvrez la page Migrate for Anthos and GKE dans Cloud Console.

    Accéder à la page Migrate for Anthos and GKE

  2. Dans l'onglet Sources, cliquez sur Ajouter une source.

  3. Sélectionnez le cluster migration-processing dans la liste déroulante, puis cliquez sur Suivant.

  4. Indiquez le nom de la migration sous la forme ledgermonolith-source.

  5. Définissez le Type de source sur Compute Engine, puis cliquez sur Suivant.

  6. Assurez-vous que le bon projet soit sélectionné en tant que projet source.

  7. Créez un compte de service qui vous permet d'utiliser Compute Engine en tant que source de migration en sélectionnant Créer un compte de service.

  8. Cliquez sur Suivant, puis sur Ajouter une source.

Créer une migration

  1. Ouvrez la page Migrate for Anthos and GKE dans Cloud Console.

    Accéder à la page Migrate for Anthos and GKE

  2. Dans l'onglet Migrations, cliquez sur Créer une migration.

  3. Définissez le nom de la migration sur ledgermonolith-migration.

  4. Sélectionnez la source de migration que vous avez créée à l'étape précédente : ledgermonolith-source.

  5. Définissez le type de système d'exploitation de la VM sur Linux.

  6. Définissez le Nom de l'instance source sur ledgermonolith-service.

  7. Définissez l'intent de migration sur Image & Data.

  8. Cliquez sur Créer une migration. L'opération peut prendre 1 à 2 minutes.

    Une fois la migration terminée, la colonne État affiche le plan de migration généré.

  9. Dans le tableau, cliquez sur le Nom de la migration ledgermonolith-migration pour ouvrir la page d'informations.

  10. Sélectionnez l'onglet YAML.

  11. Dans le plan de migration, sous dataVolumes, remplacez l'espace réservé <folder> par l'emplacement de la base de données PostgreSQL de la VM, /var/lib/postgresql. L'objet doit se présenter comme suit :

    ...
    dataVolumes:
      # Folders to include in the data volume, e.g. "/var/lib/mysql"
      # Included folders contain data and state, and therefore are automatically   excluded from a generated container image
      # Replace the placeholder with the relevant path and add more items if needed
      - folders:
        - /var/lib/postgresql
    ...
    

    Cela vous permettra de conserver la base de données tout au long de la migration.

  12. Toujours dans le plan de migration, sous deployment, assurez-vous que votre service possède le nom ledgermonolith-service, le port 8080 et le protocole TCP. L'objet doit se présenter comme suit :

    ...
    endpoints:
      - name: ledgermonolith-service
        port: 8080
        protocol: TCP
    ...
    
  13. Cliquez sur Enregistrer et générer les artefacts pour lancer le processus de migration. Ce processus prend environ sept à huit minutes.

    Les artefacts générés par Migrate for Anthos and GKE pour cette VM sont les suivants :

    • Une image Docker du processus de la VM
    • Un StatefulSet et un service pour exécuter le processus que vous venez de migrer
    • Un espace de noms et un DaemonSet pour contenir l'environnement d'exécution du conteneur
    • Un PersistentVolumeClaim et un PersistentVolume pour contenir la base de données PostgreSQL

Déployer la charge de travail migrée

Dans la section précédente, vous avez migré avec succès votre VM monolithique vers un ensemble de ressources Kubernetes pouvant être déployées dans un cluster. Vous pouvez maintenant déployer ces ressources sur votre cluster Bank of Anthos, reconfigurer l'application pour qu'elle communique avec le point de terminaison approprié pour votre nouveau service de registre et vérifier qu'il fonctionne correctement.

  1. Maintenant que les artefacts de migration ont été générés, vous pouvez vous connecter au cluster de traitement et télécharger les artefacts dans votre environnement Cloud Shell.

    gcloud container clusters get-credentials migration-processing --zone COMPUTE_ZONE --project PROJECT_ID
    migctl migration get-artifacts ledgermonolith-migration
    
  2. Connectez-vous au cluster Bank of Anthos et déployez les ressources Kubernetes générées. Installez également un environnement d'exécution de conteneur en utilisant migctl pour que votre cluster puisse exécuter le pod que vous venez de migrer.

    gcloud container clusters get-credentials boa-cluster --zone COMPUTE_ZONE
    migctl setup install --runtime
    kubectl apply -f deployment_spec.yaml
    
    Fetching cluster endpoint and auth data.
    kubeconfig entry generated for boa-cluster.
    
    applying resources to the cluster
    namespace/v2k-system created
    daemonset.apps/runtime-deploy-node created
    
    statefulset.apps/ledgermonolith-service created
    service/ledgermonolith-service-java created
    persistentvolumeclaim/data-pvc-0-4e1b2e0e-021f-422a-8319-6da201a960e5 created
    persistentvolume/pvc-4d41e0f2-569e-415d-87d9-019490f18b1c created
    
  3. Modifiez le ConfigMap contenant les hôtes du registre pour qu'il pointe vers votre nouveau pod Kubernetes, plutôt que vers la VM monolithe du registre qui n'est plus en service.

    sed -i 's/'.c.PROJECT_ID.internal'//g' ${HOME}/bank-of-anthos/src/ledgermonolith/config.yaml
    kubectl apply -f ${HOME}/bank-of-anthos/src/ledgermonolith/config.yaml
    
  4. Supprimez tous les pods pour les recréer avec votre nouvelle configuration.

    kubectl delete pods --all
    

    Vous pouvez afficher l'état des pods à l'aide de la commande suivante :

    kubectl get pods
    

    Quelques minutes peuvent être nécessaires pour que tous les pods soient opérationnels.

    NAME                           READY   STATUS    RESTARTS   AGE
    accounts-db-0                  1/1     Running   0          5m43s
    contacts-d5dcdc87c-jbrhf       1/1     Running   0          5m44s
    frontend-5768bd978-xdvpl       1/1     Running   0          5m44s
    ledgermonolith-service-0       1/1     Running   0          5m44s
    loadgenerator-8485dfd-582xv    1/1     Running   0          5m44s
    userservice-8477dfcb46-rzw7z   1/1     Running   0          5m43s
    
  5. Une fois que tous les pods sont définis sur l'état Running, vous pouvez trouver l'adresse IP externe de l'équilibreur de charge frontend.

    kubectl get service frontend
    
    NAME       TYPE           CLUSTER-IP      EXTERNAL-IP     PORT(S)        AGE
    frontend   LoadBalancer   10.79.248.161   ##.##.##.##.    80:31304/TCP   46m
    
  6. Ouvrez un navigateur et accédez à la page Web située à l'adresse IP externe indiquée ci-dessus (veillez à utiliser HTTP plutôt que HTTPS).

    http://EXTERNAL_IP
    

    Vous devriez pouvoir vous connecter avec les identifiants par défaut et voir les transactions. Les transactions que vous voyez proviennent du monolithe du registre qui a maintenant été migré vers un conteneur Kubernetes.

    Capture d&#39;écran de Bank of Anthos

Résumé

Vous avez commencé ce tutoriel avec une application active composée de plusieurs services, certains situés dans un cluster GKE et d'autres sur une VM dans Compute Engine. En seulement quelques simples étapes, sans apporter de modifications au code ni d'améliorations difficiles au code source, vous avez réussi à migrer un service monolithique avec une base de données depuis une VM vers un cluster GKE. Vous réduisez ainsi les coûts de calcul et vous rendez le développement plus facile pour les développeurs.

Nettoyer

Pour éviter des frais Google Cloud inutiles, vous devez supprimer les ressources utilisées pour ce tutoriel dès que vous avez terminé. Voici les ressources :

  • Le cluster GKE boa-cluster
  • Le cluster GKE migration-processing
  • La VM Compute Engine ledgermonolith-service

Vous pouvez supprimer ces ressources manuellement ou suivre les étapes ci-dessous afin de supprimer votre projet, ce qui supprimera également toutes les ressources associées.

  • Dans Cloud Console, accédez à la page Gérer les ressources.

    Accéder à la page Gérer les ressources

  • Dans la liste des projets, sélectionnez le projet que vous souhaitez supprimer, puis cliquez sur Supprimer.
  • Dans la boîte de dialogue, saisissez l'ID du projet, puis cliquez sur Arrêter pour supprimer le projet.
  • Étape suivante