Ce document fournit un guide étape par étape pour déployer une charge de travail basée sur une machine virtuelle (VM) dans Google Distributed Cloud à l'aide de l'environnement d'exécution de VM sur GDC. La charge de travail utilisée dans ce guide est l'exemple d'application de point de vente. Cette application représente un terminal de point de vente typique qui s'exécute sur du matériel sur site dans un magasin de vente au détail.
Dans ce document, vous allez migrer cette application d'une VM vers un cluster Google Distributed Cloud et accéder à l'interface Web de l'application. Pour migrer une VM existante vers le cluster, vous devez d'abord créer une image disque de cette VM. L'image doit ensuite être hébergée dans un dépôt auquel le cluster peut accéder. Enfin, l'URL de cette image peut être utilisée pour créer la VM. L'environnement d'exécution de VM sur GDC s'attend à ce que les images soient au format qcow2
. Si vous fournissez un autre type d'image, l'image est automatiquement convertie au format qcow2
. Pour éviter les conversions répétitives et permettre la réutilisation, vous pouvez convertir une image de disque virtuel et héberger l'image qcow2
.
Ce document utilise une image prédéfinie d'une instance de VM Compute Engine où la charge de travail s'exécute en tant que service systemd. Vous pouvez suivre la même procédure pour déployer votre propre application.
Objectifs
Avant de commencer
Pour suivre les instructions de ce document, vous avez besoin des ressources suivantes:
- Accès à un cluster Google Distributed Cloud version 1.12.0 ou ultérieure créé en suivant le guide Exécuter Google Distributed Cloud sur des VM Compute Engine avec un équilibreur de charge manuel. Ce document configure des ressources réseau pour que vous puissiez accéder à la charge de travail exécutée dans la VM via un navigateur. Si vous n'avez pas besoin de ce comportement, vous pouvez suivre ce document en utilisant n'importe quel Google Distributed Cloud.
- Une station de travail qui répond aux exigences suivantes :
Activer l'environnement d'exécution de la VM sur GDC et installer le plug-in virtctl
La définition de ressource personnalisée (CRD) de l'environnement d'exécution de la VM sur GDC fait partie de tous les clusters Google Distributed Cloud depuis la version 1.10. Une instance de la ressource personnalisée VMRuntime
est déjà créée lors de l'installation. Toutefois, elle est désactivée par défaut.
Activer l'environnement d'exécution de VM sur GDC:
sudo bmctl enable vmruntime --kubeconfig KUBECONFIG_PATH
- KUBECONFIG_PATH: chemin d'accès au fichier de configuration Kubernetes du cluster utilisateur Google Distributed Cloud
Vérifiez que
VMRuntime
est activé:kubectl wait --for=jsonpath='{.status.ready}'=true vmruntime vmruntime
La préparation de
VMRuntime
peut prendre quelques minutes. Si ce n'est pas le cas, vérifiez plusieurs fois avec de courts délais. L'exemple de sortie suivant montre queVMRuntime
est prêt:vmruntime.vm.cluster.gke.io/vmruntime condition met
Installez le plug-in virtctl pour
kubectl
:sudo -E bmctl install virtctl
L'exemple de sortie suivant montre que le processus d'installation du plug-in
virtctl
est terminé:Please check the logs at bmctl-workspace/log/install-virtctl-20220831-182135/install-virtctl.log [2022-08-31 18:21:35+0000] Install virtctl succeeded
Vérifiez l'installation du plug-in
virtctl
:kubectl virt
L'exemple de sortie suivant montre que le plug-in
virtctl
peut être utilisé aveckubectl
:Available Commands: addvolume add a volume to a running VM completion generate the autocompletion script for the specified shell config Config subcommands. console Connect to a console of a virtual machine instance. create Create subcommands. delete Delete subcommands. ...
Déployer la charge de travail basée sur des VM
Lorsque vous déployez une VM dans Google Distributed Cloud, l'environnement d'exécution des VM sur GDC attend une image de VM. Cette image sert de disque de démarrage pour la VM déployée.
Dans ce tutoriel, vous allez migrer une charge de travail basée sur une VM Compute Engine vers un cluster Google Distributed Cloud. Cette VM Compute Engine a été créée, et l'application exemple de point de vente (PoS) a été configurée pour s'exécuter en tant que service systemd. Une image disque de cette VM et de la charge de travail de l'application de point de vente a été créée dans Google Cloud. Cette image a ensuite été exportée dans un bucket Cloud Storage en tant qu'image qcow2
. Vous utiliserez cette image qcow2
prédéfinie dans les étapes suivantes.
Le code source de ce document est disponible dans le dépôt GitHub anthos-samples. Vous utiliserez les ressources de ce dépôt pour effectuer les étapes suivantes.
Déployez un
StatefulSet
MySQL. L'application de point de vente doit se connecter à une base de données MySQL pour stocker les informations sur l'inventaire et les paiements. Le dépôt du point de vente contient un exemple de fichier manifeste qui déploie unStatefulSet
MySQL, configure unConfigMap
associé et unService
Kubernetes.ConfigMap
définit les identifiants de l'instance MySQL, qui sont les identifiants transmis à l'application de point de vente.kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/point-of-sale/main/k8-manifests/common/mysql-db.yaml
Déployez la charge de travail de la VM à l'aide de l'image
qcow2
prédéfinie:kubectl virt create vm pos-vm \ --boot-disk-size=80Gi \ --memory=4Gi \ --vcpu=2 \ --image=https://storage.googleapis.com/pos-vm-images/pos-vm.qcow2
Cette commande crée un fichier YAML portant le nom de la VM (
google-virtctl/pos-vm.yaml
). Vous pouvez inspecter le fichier pour voir la définition deVirtualMachine
etVirtualMachineDisk
. Au lieu d'utiliser le plug-invirtctl
, vous auriez pu déployer la charge de travail de la VM à l'aide des définitions du modèle de ressource Kubernetes (KRM), comme indiqué dans le fichier YAML créé.Lorsque la commande s'exécute correctement, elle génère une sortie semblable à l'exemple suivant, qui explique les différentes ressources créées:
Constructing manifest for vm "pos-vm": Manifest for vm "pos-vm" is saved to /home/tfadmin/google-virtctl/pos-vm.yaml Applying manifest for vm "pos-vm" Created gvm "pos-vm"
Vérifiez l'état de la création de la VM.
La ressource
VirtualMachine
est identifiée par la ressourcevm.cluster.gke.io/v1.VirtualMachine
dans l'environnement d'exécution de VM sur GDC. Sa forme abrégée estgvm
.Lorsque vous créez une VM, les deux ressources suivantes sont créées:
- Un VirtualMachineDisk est le disque persistant dans lequel le contenu de l'image de la VM est importé.
- Un VirtualMachine est l'instance de VM elle-même. Le DataVolume est monté dans le VirtualMachine avant le démarrage de la VM.
Vérifiez l'état du VirtualMachineDisk. VirtualMachineDisk crée en interne une ressource
DataVolume
. L'image de la VM est importée dans le DataVolume, qui est monté dans la VM:kubectl get datavolume
L'exemple de sortie suivant montre le début de l'importation d'image:
NAME PHASE PROGRESS RESTARTS AGE pos-vm-boot-dv ImportScheduled N/A 8s
Vérifiez l'état du
VirtualMachine
.VirtualMachine
est à l'étatProvisioning
jusqu'à ce queDataVolume
soit entièrement importé:kubectl get gvm
L'exemple de sortie suivant montre le
VirtualMachine
en cours de provisionnement:NAME STATUS AGE IP pos-vm Provisioning 1m
Attendez que l'image de VM soit entièrement importée dans
DataVolume
. Continuez à surveiller la progression pendant l'importation de l'image:kubectl get datavolume -w
L'exemple de sortie suivant montre l'image disque en cours d'importation:
NAME PHASE PROGRESS RESTARTS AGE pos-vm-boot-dv ImportInProgress 0.00% 14s ... ... pos-vm-boot-dv ImportInProgress 0.00% 31s pos-vm-boot-dv ImportInProgress 1.02% 33s pos-vm-boot-dv ImportInProgress 1.02% 35s ...
Une fois l'importation terminée et le
DataVolume
créé, l'exemple de sortie suivant affiche lePHASE
deSucceeded
:kubectl get datavolume
NAME PHASE PROGRESS RESTARTS AGE pos-vm-boot-dv Succeeded 100.0% 14m18s
Vérifiez que
VirtualMachine
a bien été créé:kubectl get gvm
Si la création a réussi,
STATUS
afficheRUNNING
, comme illustré dans l'exemple suivant, ainsi que l'adresse IP de la VM:NAME STATUS AGE IP pos-vm Running 40m 192.168.3.250
Se connecter à la VM et vérifier l'état de l'application
L'image utilisée pour la VM inclut l'application exemple de point de vente. L'application est configurée pour démarrer automatiquement au démarrage en tant que service systemd. Vous pouvez consulter les fichiers de configuration des services systemd dans le répertoire pos-systemd-services.
Connectez-vous à la console de VM. Exécutez la commande suivante et appuyez sur Entrée après avoir vu le message
Successfully connected to pos-vm…
:kubectl virt console pos-vm
Cette commande génère l'exemple de sortie suivant, qui vous invite à saisir les informations de connexion:
Successfully connected to pos-vm console. The escape sequence is ^] pos-from-public-image login:
Utilisez le compte utilisateur et le mot de passe suivants. Ce compte a été configuré dans la VM d'origine à partir de laquelle l'image de l'environnement d'exécution de la VM sur GDC VirtualMachine a été créée.
- Identifiant de connexion :
abmuser
- Mot de passe :
abmworks
- Identifiant de connexion :
Vérifiez l'état des services de l'application de point de vente. L'application de point de vente comprend trois services: API, Inventory et Payments. Ces services s'exécutent tous en tant que services système.
Les trois services se connectent les uns aux autres via localhost. Toutefois, l'application se connecte à la base de données MySQL à l'aide d'un service Kubernetes mysql-db créé à l'étape précédente. Ce comportement signifie que la VM est automatiquement connectée au même réseau que
Pods
etServices
, ce qui permet une communication fluide entre les charges de travail de la VM et d'autres applications conteneurisées. Vous n'avez rien de plus à faire pour rendre leServices
Kubernetes accessible depuis les VM déployées à l'aide de l'environnement d'exécution de VM sur GDC.sudo systemctl status pos*
L'exemple de résultat suivant montre l'état des trois services et du service système racine,
pos.service
:● pos_payments.service - Payments service of the Point of Sale Application Loaded: loaded (/etc/systemd/system/pos_payments.service; enabled; vendor > Active: active (running) since Tue 2022-06-21 18:55:30 UTC; 1h 10min ago Main PID: 750 (payments.sh) Tasks: 27 (limit: 4664) Memory: 295.1M CGroup: /system.slice/pos_payments.service ├─750 /bin/sh /pos/scripts/payments.sh └─760 java -jar /pos/jars/payments.jar --server.port=8083 ● pos_inventory.service - Inventory service of the Point of Sale Application Loaded: loaded (/etc/systemd/system/pos_inventory.service; enabled; vendor> Active: active (running) since Tue 2022-06-21 18:55:30 UTC; 1h 10min ago Main PID: 749 (inventory.sh) Tasks: 27 (limit: 4664) Memory: 272.6M CGroup: /system.slice/pos_inventory.service ├─749 /bin/sh /pos/scripts/inventory.sh └─759 java -jar /pos/jars/inventory.jar --server.port=8082 ● pos.service - Point of Sale Application Loaded: loaded (/etc/systemd/system/pos.service; enabled; vendor preset: e> Active: active (exited) since Tue 2022-06-21 18:55:30 UTC; 1h 10min ago Main PID: 743 (code=exited, status=0/SUCCESS) Tasks: 0 (limit: 4664) Memory: 0B CGroup: /system.slice/pos.service Jun 21 18:55:30 pos-vm systemd[1]: Starting Point of Sale Application... Jun 21 18:55:30 pos-vm systemd[1]: Finished Point of Sale Application. ● pos_apiserver.service - API Server of the Point of Sale Application Loaded: loaded (/etc/systemd/system/pos_apiserver.service; enabled; vendor> Active: active (running) since Tue 2022-06-21 18:55:31 UTC; 1h 10min ago Main PID: 751 (api-server.sh) Tasks: 26 (limit: 4664) Memory: 203.1M CGroup: /system.slice/pos_apiserver.service ├─751 /bin/sh /pos/scripts/api-server.sh └─755 java -jar /pos/jars/api-server.jar --server.port=8081
Quittez la VM. Pour quitter la connexion à la console, utilisez la séquence d'échappement
^]
en appuyant surCtrl + ]
.
Accéder à la charge de travail basée sur une VM
Si vous avez configuré votre cluster en suivant le guide Exécuter Google Distributed Cloud sur des VM Compute Engine avec un équilibreur de charge manuel, une ressource Ingress
appelée pos-ingress
a déjà été créée. Cette ressource achemine le trafic de l'adresse IP externe de l'équilibreur de charge Ingress vers le service de serveur d'API de l'application exemple de point de vente.
Si votre cluster ne dispose pas de cette ressource
Ingress
, créez-la en appliquant le fichier manifeste suivant:kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/anthos-samples/main/anthos-bm-gcp-terraform/resources/manifests/pos-ingress.yaml
Créez un
Service
Kubernetes qui achemine le trafic vers la VM. La ressourceIngress
achemine le trafic vers ceService
:kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/anthos-samples/main/anthos-vmruntime/pos-service.yaml
L'exemple de sortie suivant confirme la création d'un service:
service/api-server-svc created
Obtenez l'adresse IP externe de l'équilibreur de charge
Ingress
. L'équilibreur de chargeIngress
achemine le trafic en fonction des règles de ressourcesIngress
. Vous disposez déjà d'une règlepos-ingress
pour transférer les requêtes vers le serveur d'APIService
. CeService
transmet les requêtes à la VM:INGRESS_IP=$(kubectl get ingress/pos-ingress -o jsonpath='{.status.loadBalancer.ingress[0].ip}') echo $INGRESS_IP
L'exemple de résultat suivant montre l'adresse IP de l'équilibreur de charge
Ingress
:172.29.249.159 # you might have a different IP address
Accédez à l'application à l'aide de l'adresse IP de l'équilibreur de charge Ingress dans un navigateur. Les captures d'écran ci-dessous montrent un point de vente simple avec deux articles. Vous pouvez cliquer sur les articles, plusieurs fois si vous souhaitez en commander plusieurs, et passer une commande à l'aide du bouton Payer. Cette expérience montre que vous avez déployé une charge de travail basée sur une VM dans un cluster Google Distributed Cloud à l'aide de l'environnement d'exécution de VM sur GDC.

Effectuer un nettoyage
Vous pouvez supprimer toutes les ressources créées dans ce tutoriel ou uniquement la VM et conserver les ressources réutilisables. La section Supprimer une VM dans Google Distributed Cloud décrit en détail les options disponibles.
Tout supprimer
Supprimez l'environnement d'exécution de la VM sur GDC
VirtualMachine
ainsi que toutes les ressources:kubectl virt delete vm pos-vm --all
L'exemple de sortie suivant confirme la suppression:
vm "pos-vm" used the following resources: gvm: pos-vm VirtualMachineDisk: pos-vm-boot-dv Start deleting the resources: Deleted gvm "pos-vm". Deleted VirtualMachineDisk "pos-vm-boot-dv".
Supprimer uniquement la VM
Si vous supprimez uniquement la VM, le
VirtualMachineDisk
créé est conservé. Cela permet de réutiliser cette image de VM et d'économiser du temps lors de l'importation de l'image lors de la création d'une VM.kubectl virt delete vm pos-vm
L'exemple de sortie suivant confirme la suppression:
vm "pos-vm" used the following resources: gvm: pos-vm VirtualMachineDisk: pos-vm-boot-dv Start deleting the resources: Deleted gvm "pos-vm".
Étape suivante
- La VM d'origine utilisée dans ce guide est une instance Compute Engine qui exécute Ubuntu 20.04 LTS. L'image de cette VM est accessible au public via le bucket Cloud Storage pos-vm-images. Pour en savoir plus sur la configuration de la VM et la création de son image, consultez les instructions du dépôt du point de vente.
- Lorsque vous créez une VM dans un cluster Google Distributed Cloud à l'aide de la commande
kubectl virt create vm pos-vm
, un fichier YAML portant le nom de la VM (google-virtctl/pos-vm.yaml
) est créé. Vous pouvez inspecter le fichier pour voir la définition deVirtualMachine
etVirtualMachineDisk
. Au lieu d'utiliser le plug-invirtctl
, vous pouvez déployer une VM à l'aide des définitions KRM comme indiqué dans le fichier YAML créé.