1. Introduction
Pourquoi faire migrer une application monolithique vers une architecture de microservices ? Décomposer une application en microservices présente les avantages suivants (la plupart d'entre eux proviennent du fait que les microservices sont faiblement couplés) :
- Les microservices peuvent être testés et déployés indépendamment. Plus l'unité de déploiement est petite, plus le déploiement est facile.
- Ils peuvent être intégrés dans différents langages et frameworks. Vous pouvez choisir la meilleure technologie pour chaque microservice en fonction de son cas d'utilisation spécifique.
- Ils peuvent être gérés par différentes équipes. Les limites entre les microservices permettent de dédier une équipe à un ou à plusieurs d'entre eux.
- En passant aux microservices, vous assouplissez les dépendances entre les équipes. Chaque équipe ne doit se préoccuper que des API des microservices dont elles dépendent. Elle n'a pas besoin de réfléchir à la manière dont ces microservices sont implémentés, à leurs cycles de publication, etc.
- Vous pouvez concevoir plus aisément des solutions en prévision d'une défaillance. En établissant des limites claires entre les services, il est plus facile de déterminer la marche à suivre si l'un d'entre eux ne fonctionne plus.
Toutefois, les microservices présentent quelques inconvénients par rapport aux monolithes :
- Dans la mesure où une application reposant sur des microservices correspond à un réseau de différents services qui interagissent souvent de manière peu visible, la complexité globale du système tend à augmenter.
- Contrairement aux composants internes d'un monolithe, les microservices communiquent via un réseau. Dans certaines circonstances, cela peut être considéré comme un problème de sécurité. Istio résout ce problème en chiffrant automatiquement le trafic entre les microservices.
- Il peut être difficile d'atteindre le même niveau de performance qu'avec une approche monolithique en raison des latences entre les services.
- Le comportement de votre système n'est pas causé par un seul service, mais par nombre d'entre eux et par leurs interactions. Pour cette raison, il est plus difficile de comprendre le comportement de votre système en production (son observabilité). Là encore, Istio constitue une solution au problème.
Dans cet atelier, nous allons exécuter des microservices dans Google Kubernetes Engine (GKE). Kubernetes est une plate-forme permettant d'assurer la gestion, l'hébergement, le scaling et le déploiement de conteneurs, qui constituent un moyen portable d'empaqueter et d'exécuter du code. Ceux-ci sont bien adaptés au modèle de microservices, dans lequel chaque microservice peut s'exécuter dans son propre conteneur.
Dans cet atelier, nous allons déployer une application monolithique existante sur un cluster Google Kubernetes Engine, puis la décomposer en microservices.
Schéma de l'architecture de nos microservices
Nous allons commencer par décomposer notre monolithe en trois microservices successifs : Orders (Commandes), Products (Produits) et Frontend (Interface). Nous créons une image Docker pour chaque microservice à l'aide de Cloud Build, que nous déclenchons depuis Cloud Shell. Ensuite, nous déploierons et exposerons nos microservices sur Google Kubernetes Engine (GKE) avec un service Kubernetes de type LoadBalancer. Nous suivrons cette procédure pour chacun des services tout en les refactorisant simultanément hors de notre monolithe. Pendant toute la durée de ce processus, le monolithe et les microservices s'exécuteront en même temps jusqu'à ce que vous soyez en mesure de supprimer le monolithe.
Objectifs de l'atelier
- Décomposer un monolithe en microservices
- Créer un cluster Google Kubernetes Engine
- Créer une image Docker
- Déployer des images Docker sur Kubernetes
Prérequis
- Compte Google Cloud Platform doté d'un accès administrateur pour créer un ou plusieurs projets avec le rôle de propriétaire de projet
- Connaissance de base de Docker et Kubernetes
2. Configuration de l'environnement
Configuration de l'environnement au rythme de chacun
Si vous ne possédez pas encore de compte Google (Gmail ou Google Apps), vous devez en créer un. Connectez-vous à la console Google Cloud Platform ( console.cloud.google.com) et créez un projet :
Mémorisez l'ID du projet. Il s'agit d'un nom unique permettant de différencier chaque projet Google Cloud (le nom ci-dessus est déjà pris ; vous devez en trouver un autre). Il sera désigné par le nom PROJECT_ID tout au long de cet atelier de programmation.
Ensuite, vous devez activer la facturation dans la console Developers pour pouvoir utiliser les ressources Google Cloud et activer l'API Container Engine.
Suivre cet atelier de programmation ne devrait pas vous coûter plus d'un euro. Cependant, cela peut s'avérer plus coûteux si vous décidez d'utiliser davantage de ressources ou si vous n'interrompez pas les ressources (voir la section "Effectuer un nettoyage" à la fin du présent document). Les tarifs de Google Kubernetes Engine sont disponibles sur cette page.
Les nouveaux utilisateurs de Google Cloud Platform peuvent bénéficier d'un essai sans frais avec 300$de crédits.
Google Cloud Shell
Bien que vous puissiez commander Google Cloud et Kubernetes à distance depuis votre ordinateur portable, cet atelier de programmation utilisera Google Cloud Shell, un environnement de ligne de commande fonctionnant dans le cloud.
Cette machine virtuelle basée sur Debian contient tous les outils de développement dont vous aurez besoin. Elle intègre un répertoire d'accueil persistant de 5 Go et s'exécute sur Google Cloud, ce qui améliore nettement les performances du réseau et l'authentification. Cela signifie que tout ce dont vous avez besoin pour cet atelier de programmation est un navigateur (oui, tout fonctionne sur un Chromebook).
- Pour activer Cloud Shell à partir de Cloud Console, cliquez simplement sur Activer Cloud Shell
(l'opération de provisionnement et la connexion à l'environnement ne devraient prendre que quelques minutes).
Une fois connecté à Cloud Shell, vous êtes normalement déjà authentifié et le projet PROJECT_ID est sélectionné :
gcloud auth list
Résultat de la commande
Credentialed accounts: - <myaccount>@<mydomain>.com (active)
gcloud config list project
Résultat de la commande
[core] project = <PROJECT_ID>
Si, pour une raison quelconque, le projet n'est pas défini, exécutez simplement la commande suivante :
gcloud config set project <PROJECT_ID>
Vous recherchez votre PROJECT_ID ? Vérifiez l'ID que vous avez utilisé pendant les étapes de configuration ou recherchez-le dans le tableau de bord Cloud Console :
Par défaut, Cloud Shell définit certaines variables d'environnement qui pourront s'avérer utiles pour exécuter certaines commandes dans le futur.
echo $GOOGLE_CLOUD_PROJECT
Résultat de la commande
<PROJECT_ID>
- Pour finir, définissez la configuration du projet et de la zone par défaut :
gcloud config set compute/zone us-central1-f
Vous pouvez choisir parmi différentes zones. Pour en savoir plus, consultez la page Régions et zones.
3. Cloner le dépôt source
Nous utilisons une application monolithique existante d'un site Web d'e-commerce fictif, comportant une page d'accueil simple, une page de produits et une page d'historique des commandes. Il nous suffira de cloner la source de notre dépôt git, ce qui nous permettra de nous concentrer sur la décomposition de l'application en microservices et sur leur déploiement sur Google Kubernetes Engine (GKE).
Exécutez les commandes suivantes pour cloner le dépôt git dans votre instance Cloud Shell et pour accéder au répertoire approprié. Nous allons également installer les dépendances NodeJS de manière à pouvoir tester notre monolithe avant de le déployer. L'exécution de ce script peut prendre quelques minutes.
cd ~ git clone https://github.com/googlecodelabs/monolith-to-microservices.git cd ~/monolith-to-microservices ./setup.sh
Cela clonera notre dépôt GitHub, accèdera au répertoire et installera les dépendances nécessaires pour exécuter notre application en local. L'exécution de ce script peut prendre quelques minutes.
4. Créer un cluster GKE
Maintenant que votre environnement de développement est opérationnel, vous avez besoin d'un cluster Kubernetes pour déployer votre monolithe, puis les microservices. Pour pouvoir créer un cluster, nous devons nous assurer que les API appropriées sont activées. Exécutez la commande suivante pour activer l'API Containers de manière à pouvoir utiliser Google Kubernetes Engine :
gcloud services enable container.googleapis.com
Nous sommes maintenant prêts à créer notre cluster. Exécutez la commande ci-dessous pour créer un cluster GKE nommé fancy-cluster avec 3 nœuds.
gcloud container clusters create fancy-cluster --num-nodes 3
La création du cluster peut prendre plusieurs minutes. Une fois la commande terminée, exécutez la commande suivante et affichez les trois instances de VM de nœud de calcul du cluster :
gcloud compute instances list
Résultat :
NAME ZONE MACHINE_TYPE PREEMPTIBLE INTERNAL_IP EXTERNAL_IP STATUS gke-fancy-cluster-default-pool-ad92506d-1ng3 us-east4-a n1-standard-1 10.150.0.7 XX.XX.XX.XX RUNNING gke-fancy-cluster-default-pool-ad92506d-4fvq us-east4-a n1-standard-1 10.150.0.5 XX.XX.XX.XX RUNNING gke-fancy-cluster-default-pool-ad92506d-4zs3 us-east4-a n1-standard-1 10.150.0.6 XX.XX.XX.XX RUNNING
Vous pouvez également visualiser votre cluster Kubernetes et les informations associées dans la console Google Cloud. Cliquez sur le bouton de menu en haut à gauche, faites défiler la page jusqu'à Kubernetes Engine, puis cliquez sur "Clusters". Le cluster nommé fancy-cluster doit s'afficher.
Félicitations ! Vous venez de créer votre premier cluster Kubernetes.
5. Déployer un monolithe existant
Cet atelier porte sur la décomposition d'un monolithe en microservices. Vous devez donc disposer d'une application monolithique opérationnelle. Exécutez le script suivant pour déployer une application monolithique sur notre cluster GKE aux fins de cet atelier :
cd ~/monolith-to-microservices ./deploy-monolith.sh
Accéder au monolithe
Pour trouver l'adresse IP externe de notre application monolithique, exécutez la commande suivante.
kubectl get service monolith
La sortie obtenue doit ressembler à ceci :
NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE monolith 10.3.251.122 203.0.113.0 80:30877/TCP 3d
REMARQUE : Un équilibreur de charge et une adresse IP externes doivent être provisionnés. Cette opération prendra donc un certain temps. Si le résultat présente la valeur
<pending> Patientez quelques minutes, puis réessayez.
Une fois que vous avez déterminé l'adresse IP externe de votre monolithe, copiez-la. Saisissez cette URL (telle que http://203.0.113.0) dans votre navigateur pour vérifier si le monolithe est accessible.
La page d'accueil du site Web monolithique illustrée ci-dessus doit s'afficher. Cette page d'accueil est une page statique qui sera diffusée par le microservice "Frontend" (Interface) par la suite. Votre monolithe s'exécute désormais entièrement sur Kubernetes.
6. Migrer les commandes vers un microservice
Maintenant que notre site Web monolithique existant est exécuté sur GKE, nous pouvons commencer à décomposer chaque service en microservice. En principe, il convient d'étudier les services afin de déterminer la manière dont ils peuvent être décomposés. Généralement, chaque sous-ensemble correspond à une partie spécifique de l'application (par exemple, le domaine d'activité). À des fins de démonstration, nous avons créé un exemple simple et décomposé chaque service en fonction du domaine d'activité : Orders (Commandes), Products (Produits) et Frontend (Interface). Le code a déjà été migré. Nous allons nous concentrer sur la création et le déploiement des services sur Google Kubernetes Engine (GKE).
Créer un microservice de commandes
Le premier service que nous allons décomposer est le service Orders (Commandes). Nous allons utiliser le codebase fourni et créer un conteneur Docker distinct pour ce service.
Créer un conteneur Docker avec Google Cloud Build
Comme nous avons déjà migré le codebase pour vous, la première étape consiste à créer un conteneur Docker de notre service Orders (Commandes) à l'aide de Google Cloud Build.
Normalement, vous devriez adopter une approche en deux étapes consistant à créer un conteneur Docker et à le transférer dans un registre afin de stocker l'image pour que GKE puisse l'extraire. Toutefois, vous pouvez vous simplifier la vie en utilisant Google Cloud Build pour créer le conteneur Docker et pour placer l'image dans Google Cloud Container Registry avec une seule commande. Cela nous permet de créer et de déplacer l'image vers Container Registry à l'aide d'une seule et même commande. Pour découvrir comment créer et transférer un fichier Docker manuellement, cliquez ici.
Google Cloud Build compressera les fichiers du répertoire et les déplacera vers un bucket Google Cloud Storage. Ensuite, le processus de compilation récupérera tous les fichiers du bucket et utilisera le Dockerfile pour exécuter le processus de compilation Docker. Étant donné que nous avons spécifié l'option --tag avec l'hôte en tant que gcr.io pour l'image Docker, l'image Docker résultante sera transférée vers Google Cloud Container Registry.
Exécutez les commandes suivantes pour créer votre conteneur Docker et pour le transférer vers Google Container Registry :
cd ~/monolith-to-microservices/microservices/src/orders
gcloud builds submit --tag gcr.io/${GOOGLE_CLOUD_PROJECT}/orders:1.0.0 .
Ce processus prend quelques minutes, mais une fois terminé, la sortie sur le terminal ressemble à ceci :
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- ID CREATE_TIME DURATION SOURCE IMAGES STATUS 1ae295d9-63cb-482c-959b-bc52e9644d53 2019-08-29T01:56:35+00:00 33S gs://<PROJECT_ID>_cloudbuild/source/1567043793.94-abfd382011724422bf49af1558b894aa.tgz gcr.io/<PROJECT_ID>/orders:1.0.0 SUCCESS
Pour consulter votre historique de compilation ou suivre le processus en temps réel, vous pouvez accéder à la console Google Cloud. Cliquez sur le bouton de menu en haut à gauche, puis faites défiler la page jusqu'à Outils → Cloud Build, puis cliquez sur Historique. La liste de toutes vos compilations précédentes s'affiche ici. Seule celle que vous venez de créer devrait donc apparaître.
Si vous cliquez sur l'ID de la compilation, vous pouvez consulter tous les détails la concernant, y compris la sortie du journal.
À partir de la page d'informations de la compilation, vous pouvez consulter l'image de conteneur créée en cliquant sur le nom de l'image dans la section des informations de compilation.
Déployer le conteneur sur GKE
Maintenant que nous avons conteneurisé notre site Web et transféré notre conteneur vers Google Container Registry, le moment est venu de déployer ce conteneur sur Kubernetes.
Kubernetes représente les applications sous forme de pods, qui sont eux-mêmes des unités représentant un conteneur (ou un groupe de conteneurs fortement couplés). Le pod est la plus petite unité déployable dans Kubernetes. Dans ce tutoriel, chaque pod contient uniquement votre conteneur de microservices.
Pour déployer et gérer des applications sur un cluster GKE, vous devez communiquer avec le système de gestion de clusters Kubernetes. Pour ce faire, vous utilisez généralement l'outil de ligne de commande kubectl depuis Cloud Shell.
Nous allons commencer par créer une ressource Deployment. Le déploiement gère plusieurs copies de votre application, appelées instances répliquées, et planifie leur exécution sur les nœuds individuels du cluster. Dans ce cas, le déploiement n'exécute qu'un seul pod de l'application. Les déploiements garantissent ce résultat en créant un ReplicaSet (ensemble d'instances répliquées). Le rôle du ReplicaSet est de garantir l'exécution systématique du nombre d'instances répliquées spécifié.
La commande kubectl create deployment ci-dessous demande à Kubernetes de créer sur votre cluster un déploiement nommé orders (commandes) avec 1 instance répliquée.
Exécutez la commande suivante pour déployer votre application :
kubectl create deployment orders --image=gcr.io/${GOOGLE_CLOUD_PROJECT}/orders:1.0.0
Vérifier le déploiement
Pour vérifier que le déploiement a bien été créé, exécutez la commande suivante. L'état du pod peut prendre quelques instants avant d'afficher "Running" (En cours d'exécution) :
kubectl get all
Résultat :
NAME READY STATUS RESTARTS AGE pod/monolith-779c8d95f5-dxnzl 1/1 Running 0 15h pod/orders-5bc6969d76-kdxkk 1/1 Running 0 21s NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/kubernetes ClusterIP 10.39.240.1 <none> 443/TCP 19d service/monolith LoadBalancer 10.39.241.130 34.74.209.57 80:30412/TCP 15h NAME READY UP-TO-DATE AVAILABLE AGE deployment.apps/monolith 1/1 1 1 15h deployment.apps/orders 1/1 1 1 21s NAME DESIRED CURRENT READY AGE replicaset.apps/monolith-779c8d95f5 1 1 1 15h replicaset.apps/orders-5bc6969d76 1 1 1 21s
Ce résultat nous indique plusieurs choses. Cette sortie nous présente le déploiement qui est actuellement exécuté, notre ReplicaSet avec un nombre de pods souhaité égal à 1, et notre pod qui est en cours d'exécution. Apparemment, tous les éléments ont bien été créés.
Exposez le conteneur GKE :
Nous avons déployé notre application sur GKE, mais nous ne pouvons pas y accéder en dehors du cluster. Par défaut, les conteneurs que vous exécutez sur GKE ne sont pas accessibles depuis Internet, car ils sont dépourvus d'adresses IP externes. Vous devez donc exposer explicitement votre application au trafic Internet via une ressource de service. Un service offre une compatibilité réseau et IP avec les pods de votre application. GKE crée une adresse IP externe et un équilibreur de charge (susceptible d'être facturé) pour l'application.
Lorsque nous avons déployé notre service Orders (Commandes), nous l'avons exposé sur le port 8081 en interne via un déploiement Kubernetes. Pour exposer ce service en externe, nous devons créer un service Kubernetes de type LoadBalancer pour acheminer le trafic externe du port 80 vers le port interne 8081 pour le service Orders. Exécutez la commande suivante pour exposer votre site Web à Internet :
kubectl expose deployment orders --type=LoadBalancer --port 80 --target-port 8081
Accéder au service
GKE attribue l'adresse IP externe à la ressource de service, et non à la ressource de déploiement. Si vous souhaitez connaître l'adresse IP externe provisionnée par GKE pour votre application, vous pouvez inspecter le service à l'aide de la commande kubectl get service :
kubectl get service orders
Résultat :
NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE orders 10.3.251.122 203.0.113.0 80:30877/TCP 3d
Une fois que vous avez déterminé l'adresse IP externe de votre application, copiez-la. Enregistrez cette adresse pour l'étape suivante lorsque nous modifierons notre monolithe afin de le faire pointer vers le nouveau service Orders (Commandes).
Reconfigurer le monolithe
Nous avons supprimé le service Orders (Commandes) du monolithe. Nous allons donc devoir modifier le monolithe pour le faire pointer vers le nouveau microservice Orders externe.
Lorsque vous décomposez un monolithe, vous transférez des fragments de code d'un codebase unique vers plusieurs et vous les déployez séparément. Puisque le microservice s'exécute sur un autre serveur, nous ne pouvons plus référencer l'URL des services sous la forme d'un chemin absolu. Nous devons router le trafic vers la nouvelle adresse du serveur de notre microservice Orders (Commandes). Pour ce faire, vous devrez arrêter le service monolithe afin de mettre à jour l'URL de chaque service qui a été décomposé. Prenez cet aspect en compte lorsque vous prévoierez de faire passer vos microservices et le monolithe en production au cours du processus de migration vers une architecture de microservices.
Nous devons modifier le fichier de configuration de notre monolithe pour le faire pointer vers l'adresse IP du nouveau microservice Orders (Commandes). À l'aide de l'éditeur nano, remplacez l'URL locale par l'adresse IP de notre nouveau microservice Orders. Exécutez la commande suivante pour modifier le
cd ~/monolith-to-microservices/react-app nano .env.monolith
Lors de l'ouverture de l'éditeur, votre fichier devrait se présenter comme suit :
REACT_APP_ORDERS_URL=/service/orders REACT_APP_PRODUCTS_URL=/service/products
Modifiez le format de la chaîne REACT_APP_ORDERS_URL en remplaçant sa valeur par l'adresse IP de votre microservice "Orders" (Commandes) comme suit :
REACT_APP_ORDERS_URL=http://<ORDERS_IP_ADDRESS>/api/orders REACT_APP_PRODUCTS_URL=/service/products
Appuyez sur CTRL+O, puis sur ENTER, puis sur CTRL+X pour enregistrer le fichier dans l'éditeur nano.
Vous pouvez tester votre nouveau microservice en accédant à l'URL que vous venez de définir dans ce fichier. La page Web doit renvoyer une réponse JSON de notre microservice Orders (Commandes).
Ensuite, nous devrons recréer l'interface du monolithe, puis répéter le processus de compilation pour créer le conteneur du monolithe et le redéployer sur notre cluster GKE. Pour ce faire, exécutez les commandes suivantes :
Recréez les fichiers de configuration du monolithe :
npm run build:monolith
Créer un conteneur Docker avec Google Cloud Build
cd ~/monolith-to-microservices/monolith
gcloud builds submit --tag gcr.io/${GOOGLE_CLOUD_PROJECT}/monolith:2.0.0 .
Déployer le conteneur sur GKE
kubectl set image deployment/monolith monolith=gcr.io/${GOOGLE_CLOUD_PROJECT}/monolith:2.0.0
Vous pouvez vérifier que l'application appelle désormais le nouveau microservice Orders (Commandes) en accédant à l'application monolithique dans votre navigateur et en affichant la page Orders (Commandes). Tous les ID de commande doivent se terminer par le suffixe "-MICROSERVICE", comme indiqué ci-dessous :
7. Faire migrer les produits vers un microservice
Créer un microservice de produits
Nous pouvons continuer à décomposer nos services en migrant maintenant le service Products (Produits). Nous allons suivre la même procédure que lors de l'étape précédente. Exécutez les commandes suivantes pour créer un conteneur Docker, le déployer et l'exposer via un service Kubernetes.
Créer un conteneur Docker avec Google Cloud Build
cd ~/monolith-to-microservices/microservices/src/products
gcloud builds submit --tag gcr.io/${GOOGLE_CLOUD_PROJECT}/products:1.0.0 .
Déployer le conteneur sur GKE
kubectl create deployment products --image=gcr.io/${GOOGLE_CLOUD_PROJECT}/products:1.0.0
Exposez le conteneur GKE :
kubectl expose deployment products --type=LoadBalancer --port 80 --target-port 8082
Recherchez l'adresse IP publique de nos services Products (Produits) en procédant comme vous l'avez fait pour notre service Orders (Commandes) à l'aide de la commande suivante :
kubectl get service products
Résultat :
NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE products 10.3.251.122 203.0.113.0 80:30877/TCP 3d
Enregistrez cette adresse IP pour l'étape suivante, lorsque nous reconfigurerons notre monolithe pour le faire pointer vers le nouveau microservice Products (Produits).
Reconfigurer le monolithe
À l'aide de l'éditeur nano, remplacez l'URL locale par l'adresse IP de notre nouveau microservice Products comme suit :
cd ~/monolith-to-microservices/react-app nano .env.monolith
Lors de l'ouverture de l'éditeur, votre fichier devrait se présenter comme suit :
REACT_APP_ORDERS_URL=http://<ORDERS_IP_ADDRESS>/api/orders REACT_APP_PRODUCTS_URL=/service/products
Modifiez le format de la chaîne REACT_APP_PRODUCTS_URL en remplaçant sa valeur par l'adresse IP de votre microservice Products (Produits) comme suit :
REACT_APP_ORDERS_URL=http://<ORDERS_IP_ADDRESS>/api/orders REACT_APP_PRODUCTS_URL=http://<PRODUCTS_IP_ADDRESS>/api/products
Appuyez sur CTRL+O, puis sur ENTER, puis sur CTRL+X pour enregistrer le fichier dans l'éditeur nano.
Vous pouvez tester votre nouveau microservice en accédant à l'URL que vous venez de définir dans ce fichier. La page Web doit renvoyer une réponse JSON de notre microservice Products (Produits).
Ensuite, nous devrons recréer l'interface du monolithe, puis répéter le processus de compilation pour créer le conteneur du monolithe et le redéployer sur notre cluster GKE. Pour ce faire, exécutez les commandes suivantes :
Recréez les fichiers de configuration du monolithe :
npm run build:monolith
Créer un conteneur Docker avec Google Cloud Build
cd ~/monolith-to-microservices/monolith
gcloud builds submit --tag gcr.io/${GOOGLE_CLOUD_PROJECT}/monolith:3.0.0 .
Déployer le conteneur sur GKE
kubectl set image deployment/monolith monolith=gcr.io/${GOOGLE_CLOUD_PROJECT}/monolith:3.0.0
Vous pouvez vérifier que votre application appelle désormais le nouveau microservice Products (Produits) en accédant à l'application monolithique dans votre navigateur et en affichant la page Products (Produits). Tous les noms de produit doivent commencer par le préfixe "MS-", comme indiqué ci-dessous :
8. Migrer l'interface vers un microservice
La dernière étape du processus de migration consiste à déplacer le code de l'interface (frontend) vers un microservice et à supprimer le monolithe. Lorsque nous aurons terminé cette étape, nous aurons fait migrer l'intégralité de notre monolithe vers une architecture de microservices.
Créer un microservice d'interface ("Frontend")
Suivez la même procédure que dans les deux sections précédentes pour créer un microservice Frontend (Interface).
Précédemment, lorsque nous avons recréé notre monolithe, nous avons mis à jour notre configuration pour qu'elle pointe vers notre monolithe. Maintenant, nous devons utiliser la même configuration pour notre microservice Frontend. Exécutez les commandes suivantes pour copier les fichiers de configuration de l'URL des microservices dans le codebase du microservice Frontend (Interface) :
cd ~/monolith-to-microservices/react-app cp .env.monolith .env npm run build
Une fois cette opération effectuée, nous suivrons la même procédure que dans les sections précédentes. Exécutez les commandes suivantes pour créer un conteneur Docker, le déployer et l'exposer via un service Kubernetes.
Créer un conteneur Docker avec Google Cloud Build
cd ~/monolith-to-microservices/microservices/src/frontend
gcloud builds submit --tag gcr.io/${GOOGLE_CLOUD_PROJECT}/frontend:1.0.0 .
Déployer le conteneur sur GKE
kubectl create deployment frontend --image=gcr.io/${GOOGLE_CLOUD_PROJECT}/frontend:1.0.0
Exposez le conteneur GKE :
kubectl expose deployment frontend --type=LoadBalancer --port 80 --target-port 8080
Supprimer le monolithe
Maintenant que tous nos services s'exécutent sous forme de microservices, nous pouvons supprimer notre application monolithique. Notez que dans une véritable migration, cette opération impliquerait d'autres modifications, notamment au niveau des paramètres DNS, pour faire en sorte que nos noms de domaine existants pointent vers le nouveau microservice Frontend (Interface) de notre application. Exécutez les commandes suivantes pour supprimer notre monolithe :
kubectl delete deployment monolith kubectl delete service monolith
Tester votre travail
Pour vous assurer que tout fonctionne correctement, vérifiez que l'ancienne adresse IP de votre service monolithe est désormais inopérante et que la nouvelle adresse IP de votre service Frontend (Interface) héberge bien la nouvelle application. Pour afficher la liste de l'ensemble des services et des adresses IP, exécutez la commande suivante :
kubectl get services
Vous devriez obtenir un résultat semblable à celui-ci :
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE frontend LoadBalancer 10.39.246.135 35.227.21.154 80:32663/TCP 12m kubernetes ClusterIP 10.39.240.1 <none> 443/TCP 18d orders LoadBalancer 10.39.243.42 35.243.173.255 80:32714/TCP 31m products LoadBalancer 10.39.250.16 35.243.180.23 80:32335/TCP 21m
Une fois que vous avez déterminé l'adresse IP externe de votre microservice Frontend (Interface), copiez-la. Saisissez cette URL (telle que http://203.0.113.0) dans votre navigateur pour vérifier si l'interface est accessible. Votre site Web doit être identique à celui dont vous disposiez avant de décomposer le monolithe en microservices.
9. Nettoyage
Une fois que vous êtes prêt, le moyen le plus simple de nettoyer toutes les activités effectuées consiste à supprimer le projet. La suppression du projet entraîne la suppression de toutes les ressources créées dans cet atelier de programmation, ce qui permet d'éviter des frais récurrents inattendus. Exécutez la commande suivante dans Cloud Shell, où PROJECT_ID correspond à l'ID complet du projet et non à son nom.
gcloud projects delete [PROJECT_ID]
Pour confirmer la suppression, saisissez "Y" lorsque vous y êtes invité.
10. Félicitations !
Vous avez décomposé votre application monolithique en microservices que vous avez déployés sur Google Kubernetes Engine.
Étapes suivantes
Consultez les ateliers de programmation suivants pour en savoir plus sur Kubernetes :
- Déployer, faire évoluer et mettre à jour votre site Web sur Google Kubernetes Engine
- Créer un bot Slack avec Node.js dans Kubernetes
- Livraison continue sur Kubernetes via Spinnaker
- Déployer une application Java dans Kubernetes sur Google Kubernetes Engine
Autres ressources
- Docker : https://docs.docker.com/
- Kubernetes : https://kubernetes.io/docs/home/
- Google Kubernetes Engine (GKE) : https://cloud.google.com/kubernetes-engine/docs/
- Google Cloud Build : https://cloud.google.com/cloud-build/docs/
- Google Container Registry : https://cloud.google.com/container-registry/docs/
- Migration de monolithes vers des microservices : https://cloud.google.com/solutions/migrating-a-monolithic-app-to-microservices-gke