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 le cas d'utilisation particulier de chaque microservice.
- Ils peuvent être gérés par différentes équipes. La limite entre les microservices permet 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 appliqués, à leurs cycles de publication, etc.
- Vous pouvez concevoir plus aisément des solutions en cas de défaillance. En établissant des limites claires entre les services, il est plus facile de déterminer la marche à suivre si l'un de ceux-ci 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 claire, 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.
- Le même niveau de performance que celui d'une approche monolithique peut être difficile à atteindre 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 procéderons ainsi pour chaque service tout en les refactorisant à partir de notre monolithe. Au cours du processus, le monolithe et les microservices seront tous deux exécutés jusqu'à la fin, lorsque nous serons 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.
Vous devez ensuite activer la facturation dans la Developers Console afin d'utiliser les ressources Google Cloud et d'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 décrits ici.
Les nouveaux utilisateurs de Google Cloud Platform peuvent bénéficier d'un essai sans frais de 300$.
Google Cloud Shell
Bien que Google Cloud et Kubernetes puissent être utilisés à distance depuis votre ordinateur portable, nous allons utiliser Google Cloud Shell dans cet atelier de programmation, un environnement de ligne de commande exécuté 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, avec 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
Cette opération va cloner notre dépôt GitHub, accéder au répertoire et installer les dépendances nécessaires à l'exécution locale de l'application. L'exécution de ce script peut prendre quelques minutes.
4. Créer un cluster GKE
Maintenant que vous disposez d'un environnement de développement opérationnel, nous avons besoin d'un cluster Kubernetes pour déployer notre monolithe, puis nos microservices. Avant de 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 afin de 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 l'opération 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
Sortie :
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 afficher 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 vise à expliquer comment décomposer un monolithe en microservices. Nous devons donc disposer d'une application monolithique opérationnelle. Exécutez le script suivant pour déployer une application monolithique sur notre cluster GKE pour les besoins 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: Vous devez provisionner un équilibreur de charge externe et une adresse IP pour effectuer cette opération. Cela peut donc prendre un certain temps. Si le résultat présente l'adresse IP externe comme
<pending> Veuillez patienter 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 s'exécute 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'entreprise, des commandes, des produits et du frontend. Le code a déjà été migré, et nous allons nous concentrer sur la création et le déploiement des services sur Google Kubernetes Engine (GKE).
Créer un microservice Orders
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 à l'aide de 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 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. Mais pour vous faciliter la tâche, nous pouvons utiliser Google Cloud Build pour créer le conteneur Docker et placer l'image dans Google Cloud Container Registry en une seule commande. Cela nous permet d'exécuter une seule commande pour créer et déplacer l'image vers Container Registry. 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 afficher votre historique de compilation ou observer le processus en temps réel, vous pouvez accéder à la console Google Cloud. Cliquez sur le bouton de menu en haut à gauche, faites défiler la page vers le bas 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.
Sur la page d'informations sur la compilation, vous pouvez afficher l'image de conteneur créée en cliquant sur son nom dans la section "Informations sur la compilation".
Déployer le conteneur sur GKE
Maintenant que nous avons conteneurisé notre site Web et transféré notre conteneur vers Google Container Registry, il est temps de déployer ce conteneur sur Kubernetes.
Kubernetes représente les applications sous forme de pods, qui sont des unités faisant référence à 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 votre 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 amène Kubernetes à créer sur votre cluster un déploiement nommé orders 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. Il peut s'écouler quelques instants avant que le pod passe à l'état "Running" (En cours d'exécution) :
kubectl get all
Sortie :
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 montre plusieurs choses. Nous pouvons voir notre déploiement qui est en cours, 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 afin d'acheminer le trafic du port 80 vers le port interne 8081 du service Orders (Commandes). 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 au 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
Sortie :
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-le pour l'étape suivante lorsque nous modifierons notre monolithe pour le faire pointer vers notre nouveau service Orders (Commandes).
Reconfigurer le monolithe
Comme nous avons supprimé le service Orders (Commandes) du monolithe, nous allons devoir modifier le monolithe pour le faire pointer vers le nouveau microservice Orders externe.
Lors de la décomposition d'un monolithe, nous supprimons les fragments de code d'un codebase unique vers plusieurs codebases et nous les déployons séparément. Étant donné que le microservice s'exécute sur un autre serveur, nous ne pouvons plus référencer les URL de nos services en tant que chemins absolus. Nous devons donc acheminer les requêtes vers la nouvelle adresse du serveur de notre microservice Orders (Commandes). Notez que cela nécessitera un temps d'arrêt du service monolith 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 mettre à jour notre fichier de configuration dans 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 (Commandes). 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 REACT_APP_ORDERS_URL en le remplaçant 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, 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 reconstruire notre interface monolithique et 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 à l'aide de 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 votre 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 ensuite le service Products (Produits). Nous allons suivre la même procédure qu'à 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 à l'aide de 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 notre service Products (Produits) en procédant comme nous l'avons fait pour le service Orders (Commandes) à l'aide de la commande suivante:
kubectl get service products
Sortie :
NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE products 10.3.251.122 203.0.113.0 80:30877/TCP 3d
Enregistrez l'adresse IP pour l'étape suivante, lorsque nous reconfigurerons notre monolithe pour le faire pointer vers notre nouveau microservice Products (Produits).
Reconfigurer le monolithe
À l'aide de l'éditeur nano, remplacez l'URL locale par l'adresse IP de nos nouveaux microservices Products:
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 REACT_APP_PRODUCTS_URL en le remplaçant 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, 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 reconstruire notre interface monolithique et 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 à l'aide de 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 dernières étapes pour créer un microservice Frontend (Interface).
Précédemment, lorsque nous avons recréé notre monolithe, nous avons mis à jour notre configuration pour pointer vers notre monolithe, mais nous devons maintenant utiliser la même configuration pour notre microservice Frontend (Interface). 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 lors des étapes 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 à l'aide de 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 en tant que 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 le monolithe:
kubectl delete deployment monolith kubectl delete service monolith
Tester votre travail
Pour vérifier que tout fonctionne correctement, vérifiez que l'ancienne adresse IP de votre service "monolith" ne fonctionne pas 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 le même qu'avant la décomposition du 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 celle de toutes les ressources créées dans cet atelier de programmation afin d'éviter que des frais récurrents ne soient facturés. Exécutez la commande suivante dans Cloud Shell, où PROJECT_ID correspond à l'ID complet du projet, et pas seulement au nom du projet.
gcloud projects delete [PROJECT_ID]
Confirmez la suppression en saisissant "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éployez, faites évoluer et mettez à jour votre site Web sur Google Kubernetes Engine
- Créer un bot Slack avec Node.js dans Kubernetes
- Livraison continue sur Kubernetes à l'aide de 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