Migrer une VM monolithique – Migration et déploiement
Avec une configuration de cluster de traitement et une installation de Migrate to Containers, 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.
Dans Google Cloud Console, accédez à la page "Instances de VM".
Sélectionnez la case située à l'extrémité gauche de la ligne de la VM
ledgermonolith-service.En haut de la page, cliquez sur le bouton Arrêter pour arrêter la VM.
Attendez que la VM soit complètement arrêtée. L'opération peut prendre 1 à 2 minutes.
Migrer la VM
Avant de pouvoir migrer la VM, vous devez créer une source de migration qui représente la plate-forme source (Compute Engine ou VMWare).
Ajouter une source
Ouvrez la page "Migrate to Containers" dans la console Google Cloud.
Dans l'onglet Sources et candidats, cliquez sur Ajouter une source.
Sous Sélectionner un cluster de traitement, choisissez le cluster de traitement de la migration dans la liste déroulante et cliquez sur Suivant.
Spécifiez le nom de la source, par exemple
ledgermonolith-source.Définissez le Type de source sur Compute Engine, puis cliquez sur Suivant.
Assurez-vous que le bon projet soit sélectionné en tant que projet source.
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.
Cliquez sur Continuer, puis sur Ajouter une source.
Créer une migration
Ouvrez la page "Migrate to Containers" dans la console Google Cloud.
Dans l'onglet Migrations, cliquez sur Créer une migration.
Définissez le nom de la migration sur
ledgermonolith-migration.Sélectionnez la source de migration que vous avez créée à l'étape précédente :
ledgermonolith-source.Définissez le Type de charge de travail sur
Linux system container.Définissez le Nom de l'instance source sur
ledgermonolith-service.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é.
Dans le tableau, cliquez sur le Nom de la migration
ledgermonolith-migrationpour ouvrir la page d'informations.Dans l'onglet Configuration des données, créez un volume pour migrer la base de données PostgreSQL de la VM,
/var/lib/postgresql. La configuration doit se présenter comme suit :volumes: - deploymentPvcName: ledgermonolith-db folders: # Folders to include in the data volume, e.g. "/var/lib/postgresql" # Included folders contain data and state, and therefore are automatically excluded from a generated container image - /var/lib/postgresql newPvc: spec: accessModes: - ReadWriteOnce resources: requests: storage: 10GCela vous permettra de conserver la base de données tout au long de la migration. Cliquez sur Enregistrer.
Toujours dans l'onglet Plan de migration, sous
deployment, assurez-vous que votre service possède le nomledgermonolith-service, le port8080et le protocoleTCP. L'objet doit se présenter comme suit :... endpoints: - name: ledgermonolith-service port: 8080 protocol: TCP ...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 to Containers 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.
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
cd ${HOME}/bank-of-anthos/src/ledgermonolith/migctl migration get-artifacts ledgermonolith-migrationConnectez-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
migctlpour que votre cluster puisse exécuter le pod que vous venez de migrer.gcloud container clusters get-credentials boa-cluster --zone COMPUTE_ZONE --project=PROJECT_ID
migctl setup install --runtimekubectl apply -f ${HOME}/bank-of-anthos/src/ledgermonolith/deployment_spec.yamlFetching 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
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.yamlkubectl apply -f ${HOME}/bank-of-anthos/src/ledgermonolith/config.yamlSupprimez 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
Une fois que tous les pods sont définis sur l'état
Running, vous pouvez trouver l'adresse IP externe de l'équilibreur de chargefrontend.kubectl get service frontend
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE frontend LoadBalancer 10.79.248.161 ##.##.##.##. 80:31304/TCP 46m
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.
Étapes suivantes
Maintenant que vous avez appris à créer et à personnaliser un plan de migration à partir de votre charge de travail de VM, et à migrer votre VM vers des artefacts conteneurisés, vous pouvez passer à la section suivante du tutoriel, Optimisation.
Si vous terminez le tutoriel après cette section, n'oubliez pas de nettoyer votre projet et vos ressources Google Cloud.
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.