1. Présentation
Il n'est pas toujours possible ni réalisable de réécrire ou de réorganiser manuellement les applications existantes pour qu'elles fonctionnent sur Kubernetes. Migrate for Anthos peut vous aider à moderniser vos applications existantes et à les exécuter dans Kubernetes. Dans cet atelier de programmation, vous allez migrer une application Web existante hébergée sur Compute Engine vers Kubernetes Engine à l'aide de Migrate for Anthos.
Points abordés
- Déployer Migrate for Anthos sur un cluster Kubernetes
- Créer un conteneur dans un StatefulSet à partir d'une instance Compute Engine existante
- Déployer votre conteneur sur Kubernetes et le configurer avec un équilibreur de charge
Prérequis
- Un projet Google Cloud avec la facturation configurée. Si vous n'en avez pas, vous devrez en créer un.
2. Configuration
Cet atelier de programmation peut être exécuté entièrement sur Google Cloud Platform, sans installation ni configuration locales.
Activer les API
Avant de commencer, assurez-vous d'activer les API requises dans votre projet Google Cloud :
Créer un serveur Web d'instance Compute
Commençons par créer une instance de calcul que nous utiliserons pour héberger notre serveur Web nginx initial, ainsi que les règles de pare-feu qui nous permettront d'afficher la page de destination par défaut du serveur Web. Il existe plusieurs façons de procéder, mais pour plus de simplicité, nous utiliserons Cloud Shell.
Dans Cloud Shell, exécutez la commande ci-dessous :
gcloud compute instances create webserver --zone=us-central1-a && \ gcloud compute firewall-rules create default-allow-http --allow=tcp:80
La première moitié de cette commande créera une instance Google Cloud dans la zone us-central1-a, tandis que la seconde moitié créera une règle de pare-feu nommée "default-allow-http" qui autorisera le trafic HTTP dans notre réseau.
Une fois l'instance créée, un tableau contenant ses détails s'affiche. Notez l'adresse IP externe, car nous en aurons besoin pour vérifier que notre serveur Web est en cours d'exécution.
Une fois l'instance opérationnelle, nous pouvons nous y connecter en SSH depuis Cloud Shell pour installer nginx et démarrer le serveur Web :
gcloud compute ssh --zone us-central1-a webserver
Une fois connecté à notre instance de calcul, installez nginx :
sudo apt install nginx
Déconnectez-vous de la session SSH avec la commande logout.
Vérifions que notre serveur Web est en cours d'exécution en saisissant l'adresse IP externe de l'instance dans notre navigateur. L'écran de bienvenue NGINX par défaut doit s'afficher :
Ce serveur Web servira d'ancienne application Web que nous migrerons vers Kubernetes à l'aide de Migrate for Anthos.
3. Cluster Kubernetes avec Migrate for Anthos
Nous allons ensuite créer un cluster GKE dans lequel nous migrerons le serveur Web Compute Engine. Dans la console Cloud, exécutez la commande suivante :
gcloud container clusters create my-gke-cluster \ --zone us-central1-a \ --cluster-version 1.13 \ --machine-type n1-standard-4 \ --image-type "UBUNTU" \ --num-nodes 1 \ --enable-stackdriver-kubernetes
Laissez cette commande s'exécuter pendant quelques minutes. Une fois le cluster créé, vous recevrez des informations le concernant :
Ensuite, accédez à la place de marché GCP pour déployer Migrate for Anthos :
Sur la page Marketplace de Migrate for Anthos, cliquez sur "Configurer" et, si vous y êtes invité, sélectionnez votre projet dans la liste. La page suivante présente un formulaire avec des valeurs par défaut saisies. Assurez-vous que le cluster sélectionné est celui que nous venons de créer, puis cliquez sur Déployer :
Migrate for Anthos devrait maintenant être déployé sur votre cluster Kubernetes. Une fois le déploiement terminé, l'état "OK" s'affiche sur la page Applications Kubernetes Engine :
4. D'une instance de calcul à un StatefulSet
Nous disposons d'un cluster Kubernetes exécutant Migrate for Anthos. Nous pouvons donc commencer le processus de migration. Pour déployer notre instance de calcul dans un cluster Kubernetes, nous allons arrêter notre instance Compute Engine afin de pouvoir prendre des instantanés des disques. Avant de continuer, notez l'ID de l'instance, dont nous aurons besoin plus tard :
gcloud compute instances describe webserver --zone us-central1-a | grep ^id
Arrêtons notre instance de calcul :
gcloud compute instances stop webserver --zone us-central1-a
Maintenant que l'instance est arrêtée, nous pouvons créer un instantané des disques en toute sécurité en exécutant le script suivant. Veillez à insérer votre ID de projet et votre ID d'instance :
python3 /google/migrate/anthos/gce-to-gke/clone_vm_disks.py \ -p <project-id> -i <instance-id> \ -z us-central1-a \ -T us-central1-a \ -A webserver-statefulset \ -o containerized-webserver.yaml
Avec ces indicateurs, clone_vm_disks.py :
- Vérifier que votre instance GCE est arrêtée
- Créez un instantané de chacun des disques de votre instance.
- Créez un disque à partir de chaque instantané.
- supprimer les instantanés qu'il a créés ;
- Générez un fichier YAML dans votre répertoire de travail actuel pour déployer un ensemble avec état qui hébergera votre serveur Web.
Le fichier YAML généré provisionnera un ensemble avec état dans notre cluster Kubernetes, ainsi que les revendications de volume persistant nécessaires pour monter les disques copiés sur notre conteneur de serveur Web. Nous pouvons appliquer ces modifications avec kubectl :
kubectl apply -f containerized-webserver.yaml
Vérifiez l'état du webserver-statefulset sur la page "Charges de travail" :
Il est normal que l'état indique "Pods en attente" pendant quelques minutes après l'exécution de kubectl apply. Passez à l'étape suivante une fois que l'état indique "OK".
5. Exposer le cluster à l'équilibreur de charge
À ce stade, notre cluster Kubernetes devrait exécuter notre serveur Web en tant que StatefulSet, mais nous devrons également exposer son conteneur à un équilibreur de charge pour accéder à notre serveur Web via une adresse IP externe. Dans Cloud Shell, créez un fichier nommé loadbalancer.yaml avec le contenu suivant :
loadbalancer.yaml
apiVersion: v1
kind: Service
metadata:
name: webserver-loadbalancer
spec:
type: LoadBalancer
selector:
app: webserver-statefulset
ports:
- protocol: TCP
port: 80
targetPort: 80
Appliquez-le maintenant avec kubectl :
kubectl apply -f loadbalancer.yaml
Nous pouvons utiliser kubectl pour récupérer l'adresse IP externe du service webserver-container :
kubectl get services
Si nous saisissons l'adresse IP externe dans notre navigateur, nous devrions obtenir le même écran d'accueil nginx par défaut que précédemment :
On a réussi ! Notre serveur Web GCE est désormais hébergé sur Kubernetes. Bravo !
6. Stackdriver Monitoring
Métriques
En tant que service Kubernetes géré, Kubernetes Engine est automatiquement instrumenté pour la journalisation et la surveillance avec Stackdriver. Examinons quelques-unes des métriques que Stackdriver capture automatiquement pour nous.
Cliquez sur le lien "Monitoring" dans le menu des produits. Si vous y accédez pour la première fois depuis votre projet, la configuration de votre espace de travail peut prendre quelques minutes.
Une fois la page chargée, pointez sur "Ressources" dans le volet de gauche, puis sélectionnez "Kubernetes Engine NOUVEAU" dans le menu.
Chaque ligne du tableau de bord présenté ici représente une ressource Kubernetes. Vous pouvez passer de la vue "Infrastructure" à la vue "Charges de travail" ou "Services" à l'aide des liens situés au-dessus du tableau de bord.
Dans la vue "Charges de travail", développez "my-gke-cluster", puis accédez à default > webserver-statefulset > webserver-statefulset-0 > webserver-statefulset. Cliquez sur le conteneur du StatefulSet du serveur Web. Vous y trouverez des métriques prêtes à l'emploi capturées par Stackdriver, y compris l'utilisation de la mémoire et du processeur.
Les graphiques affichés dans ce tableau de bord sont ceux que nous pourrons utiliser pour créer un tableau de bord personnalisé.
Tableaux de bord personnalisés
Stackdriver nous permet de créer des tableaux de bord personnalisés que nous pouvons utiliser pour organiser les graphiques de toutes les données de métriques à notre disposition. Créons un tableau de bord personnalisé pour obtenir un aperçu de certaines métriques de notre serveur Web.
Dans le volet de gauche, pointez sur "Tableaux de bord", puis cliquez sur "Créer un tableau de bord".
Maintenant que nous avons notre tableau de bord vide, nous pouvons ajouter les métriques que nous souhaitons surveiller. Donnons à notre tableau de bord sans titre un nom utile, comme "Mes conteneurs de serveur Web", puis cliquons sur "Ajouter un graphique" en haut à droite :
Vous vous souvenez des métriques prêtes à l'emploi ? Ajoutons un graphique pour l'utilisation du processeur du conteneur. Dans le champ "Titre du graphique", saisissez "Utilisation du processeur". Dans la zone "Find resource type and metric" (Rechercher un type de ressource et une métrique), saisissez request_utilization, puis sélectionnez "CPU request utilization" (Utilisation des ressources de processeur demandées) dans la liste filtrée. Cette sélection remplira automatiquement les champs "Type de ressource" et "Métrique".
Ensuite, nous allons filtrer par project_id (si nous avons plusieurs projets) et container_name. Dans la zone de filtre, saisissez project_id, sélectionnez-le dans la liste filtrée, puis sélectionnez votre projet dans le champ "Valeur". Nous devons également filtrer par container_name. Dans la zone "Filtre", saisissez container_name, sélectionnez-le dans la liste filtrée, puis sélectionnez "webserver-statefulset" dans le champ "Valeur". Cliquez sur "Enregistrer".
Nous avons maintenant un tableau de bord avec notre premier graphique.
7. Test de disponibilité et règle d'alerte
Avec Stackdriver, nous pouvons configurer des alertes pour nous avertir lorsque des métriques atteignent les valeurs de seuil que nous spécifions. Par exemple, nous pouvons demander à Stackdriver de nous envoyer un e-mail lorsque l'utilisation du processeur de la dernière étape dépasse un certain seuil pendant une période prolongée, ce qui peut indiquer un problème avec notre application. Pour vous montrer à quoi ressemblent ces alertes, configurons une vérification du temps d'activité, puis simulons une panne.
Dans le volet de gauche, sélectionnez "Tests de disponibilité", puis "Vue d'ensemble des tests de disponibilité" :
Comme le suggère la page "Tests de disponibilité", configurons notre premier test de disponibilité. Cliquez sur le bouton Add Uptime Check (Ajouter un test de disponibilité) en haut à droite de la page.
Dans le formulaire suivant, saisissez "Endpoint Uptime" (Temps d'activité du point de terminaison) comme titre et l'adresse IP externe de votre équilibreur de charge comme nom d'hôte.
Cliquez sur Enregistrer. Vous serez alors invité à créer une règle d'alerte associée :
Cliquez sur Créer une règle d'alerte.
Nommez-la "Endpoint Uptime Policy". Dans la section Configuration, définissez "La condition se déclenche si" sur "À chaque infraction de série temporelle", puis cliquez sur Enregistrer.
Nous n'avons pas encore tout à fait terminé. Nous allons ensuite spécifier un canal de notification pour être avertis lorsque notre règle d'alerte est enfreinte. Dans le menu déroulant "Type de canal de notification", sélectionnez "E-mail", puis saisissez une adresse e-mail valide.
Cliquez sur Add Notification Channel (Ajouter un canal de notification). Enfin, en bas du formulaire, nommez la règle "Web App Uptime" (Temps d'activité de l'application Web), puis cliquez sur "Save" (Enregistrer).
Pour voir à quoi ressemblera une alerte, ouvrez à nouveau Cloud Shell dans la console Cloud. La commande suivante arrêtera le service nginx exécuté dans notre pod de serveur Web :
kubectl exec -t webserver-statefulset-0 -- /bin/bash -c "nginx -s stop"
Au bout de quelques minutes, vous devriez recevoir un e-mail vous informant de l'indisponibilité :
Annulons cela. Retournons dans Cloud Shell et redémarrons nginx :
kubectl exec -t webserver-statefulset-0 -- /bin/bash -c "nginx"
Au bout de quelques minutes , vous recevrez un autre e-mail Stackdriver, cette fois avec de meilleures nouvelles :
8. Nettoyage
Maintenant que nous avons migré de GCE vers GKE avec Migrate for Anthos, nettoyons notre projet de toutes les ressources que nous avons créées.
Supprimer le projet
Si vous le souhaitez, vous pouvez supprimer l'intégralité du projet. Dans la console GCP, accédez à la page Cloud Resource Manager :
Dans la liste des projets, sélectionnez celui dans lequel vous avez travaillé, puis cliquez sur Supprimer. Vous serez alors invité à saisir l'ID du projet. Saisissez-le, puis cliquez sur Arrêter.
Si vous préférez supprimer les différents composants un par un, passez à la section suivante.
Stackdriver
Tableau de bord
Sur la page de votre tableau de bord, cliquez sur l'icône Paramètres 
en haut de la page, puis sélectionnez Supprimer le tableau de bord.
Règle d'alerte
Sur la page Règles, sélectionnez Supprimer dans le menu Actions 
à droite de chaque règle que vous avez créée.
Test de disponibilité
Sur la page "Tests de disponibilité", sélectionnez Supprimer dans le menu "Actions" à droite de chaque test que vous avez créé.
GCE et Kubernetes
Instance Google Compute Engine
gcloud compute instances delete webserver --zone=us-central1-a
Cluster Kubernetes (incluant Migrate for Anthos, l'ensemble avec état et le service d'équilibreur de charge)
gcloud container clusters delete my-gke-cluster --zone=us-central1-a
Disques
Notre ensemble avec état utilisait un disque que nous avions créé. Utilisez ce qui suit pour récupérer le nom :
gcloud compute disks list --filter=webserver
En utilisant votre nom de disque à la place du mien, supprimez-le avec la commande suivante :
gcloud compute disks delete vls-690d-webserver --zone=us-central1-a
Tout est propre !
9. Félicitations !
Bravo ! Vous avez migré votre serveur Web d'une instance GCE vers un cluster Kubernetes à l'aide de Migrate for Anthos.
Points abordés
- Nous avons migré un serveur Web de GCE vers un cluster Kubernetes à l'aide de Migrate for Anthos.
- Nous avons ouvert notre serveur Web avec état au monde entier en l'exposant via un service d'équilibrage de charge Kubernetes.
- Nous avons activé Stackdriver et créé un tableau de bord personnalisé.
- Nous avons configuré un test de disponibilité ainsi qu'une règle d'alerte pour nous avertir lorsque notre serveur Web est hors service.