Points de contrôle
Create a GKE Cluster
/ 20
Deploy Existing Monolith
/ 20
Migrate Orders to a microservice
/ 20
Migrate Products to microservice
/ 20
Migrate Frontend to microservice
/ 20
Migrer un site Web monolithique vers une architecture de microservices sur Google Kubernetes Engine
GSP699
Présentation
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, vous allez déployer une application monolithique existante sur un cluster Google Kubernetes Engine, puis vous la décomposerez en microservices. 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.
Schéma de l'architecture de nos microservices
Vous allez commencer par décomposer le monolithe en trois microservices successifs : "Orders" (Commandes), "Products" (Produits) et "Frontend" (Interface). Ensuite, vous créerez une image Docker pour chaque microservice à l'aide de Cloud Build, puis vous déploierez et exposerez les microservices sur Google Kubernetes Engine (GKE) avec un service Kubernetes de type LoadBalancer. Vous suivrez cette procédure pour chacun des services tout en les refactorisant simultanément hors du 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
Configuration de l'environnement
Avant de cliquer sur le bouton "Démarrer l'atelier"
Lisez ces instructions. Les ateliers sont minutés, et vous ne pouvez pas les mettre en pause. Le minuteur, qui démarre lorsque vous cliquez sur Démarrer l'atelier, indique combien de temps les ressources Google Cloud resteront accessibles.
Cet atelier pratique vous permet de suivre vous-même les activités dans un véritable environnement cloud, et non dans un environnement de simulation ou de démonstration. Nous vous fournissons des identifiants temporaires pour vous connecter à Google Cloud le temps de l'atelier.
Pour réaliser cet atelier :
- vous devez avoir accès à un navigateur Internet standard (nous vous recommandons d'utiliser Chrome) ;
- vous disposez d'un temps limité ; une fois l'atelier commencé, vous ne pouvez pas le mettre en pause.
Démarrer l'atelier et se connecter à la console Google Cloud
-
Cliquez sur le bouton Démarrer l'atelier. Si l'atelier est payant, un pop-up s'affiche pour vous permettre de sélectionner un mode de paiement. Sur la gauche, vous trouverez le panneau Détails concernant l'atelier, qui contient les éléments suivants :
- Le bouton Ouvrir la console Google
- Le temps restant
- Les identifiants temporaires que vous devez utiliser pour cet atelier
- Des informations complémentaires vous permettant d'effectuer l'atelier
-
Cliquez sur Ouvrir la console Google. L'atelier lance les ressources, puis ouvre la page Se connecter dans un nouvel onglet.
Conseil : Réorganisez les onglets dans des fenêtres distinctes, placées côte à côte.
Remarque : Si la boîte de dialogue Sélectionner un compte s'affiche, cliquez sur Utiliser un autre compte. -
Si nécessaire, copiez le nom d'utilisateur inclus dans le panneau Détails concernant l'atelier et collez-le dans la boîte de dialogue Se connecter. Cliquez sur Suivant.
-
Copiez le mot de passe inclus dans le panneau Détails concernant l'atelier et collez-le dans la boîte de dialogue de bienvenue. Cliquez sur Suivant.
Important : Vous devez utiliser les identifiants fournis dans le panneau de gauche. Ne saisissez pas vos identifiants Google Cloud Skills Boost. Remarque : Si vous utilisez votre propre compte Google Cloud pour cet atelier, des frais supplémentaires peuvent vous être facturés. -
Accédez aux pages suivantes :
- Acceptez les conditions d'utilisation.
- N'ajoutez pas d'options de récupération ni d'authentification à deux facteurs (ce compte est temporaire).
- Ne vous inscrivez pas aux essais offerts.
Après quelques instants, la console Cloud s'ouvre dans cet onglet.
Activer Cloud Shell
Cloud Shell est une machine virtuelle qui contient de nombreux outils pour les développeurs. Elle comprend un répertoire d'accueil persistant de 5 Go et s'exécute sur Google Cloud. Cloud Shell vous permet d'accéder via une ligne de commande à vos ressources Google Cloud.
- Cliquez sur Activer Cloud Shell
en haut de la console Google Cloud.
Une fois connecté, vous êtes en principe authentifié et le projet est défini sur votre ID_PROJET. Le résultat contient une ligne qui déclare YOUR_PROJECT_ID (VOTRE_ID_PROJET) pour cette session :
gcloud est l'outil de ligne de commande pour Google Cloud. Il est préinstallé sur Cloud Shell et permet la complétion par tabulation.
- (Facultatif) Vous pouvez lister les noms des comptes actifs à l'aide de cette commande :
-
Cliquez sur Autoriser.
-
Vous devez à présent obtenir le résultat suivant :
Résultat :
- (Facultatif) Vous pouvez lister les ID de projet à l'aide de cette commande :
Résultat :
Exemple de résultat :
gcloud, dans Google Cloud, accédez au guide de présentation de la gcloud CLI.
Définissez la configuration du projet et de la zone par défaut :
gcloud config set compute/zone us-central1-f
Cloner le dépôt source
Vous allez utiliser 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é. Vous allez également installer les dépendances NodeJS de manière à pouvoir tester votre monolithe avant de le déployer :
cd ~
git clone https://github.com/googlecodelabs/monolith-to-microservices.git
cd ~/monolith-to-microservices
./setup.sh
L'exécution de ce script peut prendre quelques minutes.
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 être en mesure de créer un cluster, vous devez commencer par vérifier que les API appropriées sont bien 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
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 cette opération terminée, exécutez la commande suivante pour afficher 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-central1-f n1-standard-1 10.150.0.7 XX.XX.XX.XX RUNNING
gke-fancy-cluster-default-pool-ad92506d-4fvq us-central1-f n1-standard-1 10.150.0.5 XX.XX.XX.XX RUNNING
gke-fancy-cluster-default-pool-ad92506d-4zs3 us-central1-f 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 Cloud Console. Pour ce faire, cliquez sur le menu de navigation, faites-le défiler vers le bas jusqu'à la section 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.
Cliquez sur Check my progress (Vérifier ma progression) pour vérifier l'objectif.
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 votre cluster GKE :
cd ~/monolith-to-microservices
./deploy-monolith.sh
Accéder au monolithe
Pour trouver l'adresse IP externe de l'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
Si la sortie présente la valeur <pending> (En attente) pour l'adresse IP externe, patientez une minute, puis réexécutez la commande.
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.
Cliquez sur Check my progress (Vérifier ma progression) pour vérifier l'objectif.
Faire migrer les commandes vers un microservice
Maintenant que votre site Web monolithique s'exécute sur GKE, vous allez 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é). Dans cet atelier, vous allez créer un exemple et décomposer chaque service en fonction du domaine d'activité : "Orders" (Commandes), "Products" (Produits) et "Frontend" (Interface). Le code a déjà été migré pour vous, ce qui vous permet de vous concentrer sur la création et le déploiement des services sur Google Kubernetes Engine (GKE).
Créer un microservice de commandes ("Orders")
Le premier service à décomposer est le service "Orders" (Commandes). Vous allez utiliser le codebase fourni et créer un conteneur Docker distinct pour ce service.
Créer un conteneur Docker à l'aide de Cloud Build
Le codebase est déjà disponible, vous allez donc commencer par créer un conteneur Docker de votre service "Orders" (Commandes) avec Cloud Build.
En temps normal, vous devez adopter une approche en deux étapes consistant à créer un conteneur Docker, puis à le transférer vers un registre afin de stocker l'image pour que GKE puisse l'extraire. Toutefois, vous pouvez utiliser Cloud Build pour créer le conteneur Docker et pour placer l'image dans Container Registry en une seule opération. Cela vous 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 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 l'option --tag est spécifiée 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 une minute, 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 visualiser votre historique de compilation ou observer le processus en temps réel, cliquez sur le bouton du menu de navigation dans le coin supérieur gauche de la console, faites défiler le menu vers le bas jusqu'à la section "Tools" (Outils), puis cliquez sur Cloud Build > History (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 l'onglet "Execution Details" (Détails de l'exécution).
Déployer le conteneur sur GKE
Maintenant que vous avez conteneurisé le site Web et transféré le 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 des unités représentant un conteneur (ou un groupe de conteneurs étroitement 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.
Commencez par créer une ressource de déploiement. Le déploiement gère plusieurs copies de votre application, appelées instances dupliquées, et planifie leur exécution sur les nœuds individuels du cluster. Dans ce cas précis, 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 dupliquées). Le rôle du ReplicaSet est de garantir l'exécution systématique du nombre d'instances dupliqué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 dupliqué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 :
kubectl get all
Il peut s'écouler quelques instants avant que le pod passe à l'état "Running" (En cours d'exécution).
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
Cette sortie vous présente le déploiement qui est actuellement exécuté, le replicaset avec un nombre de pods souhaité égal à 1, et le pod qui est en cours d'exécution. Apparemment, tous les éléments ont bien été créés.
Vous pouvez également visualiser vos déploiements Kubernetes dans Cloud Console. Pour ce faire, accédez au menu de navigation, puis cliquez sur Kubernetes Engine > Workloads (Charges de travail).
Exposer 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.
Pour les besoins de cet atelier, l'exposition du service a été simplifiée. Généralement, vous devez sécuriser vos points de terminaison publics à l'aide d'une passerelle API. Pour connaître les bonnes pratiques concernant les microservices, cliquez ici.
Lorsque vous avez déployé le service "Orders" (Commandes), vous l'avez exposé sur le port 8081 en interne via un déploiement Kubernetes. Pour exposer ce service en externe, vous devez créer un service Kubernetes de type LoadBalancer pour acheminer le trafic du port 80 en externe vers le port interne 8081.
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
Sortie :
NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE
orders 10.3.251.122 203.0.113.0 80:30877/TCP 3s
Une fois que vous avez déterminé l'adresse IP externe de l'application, copiez-la. Enregistrez cette adresse pour l'étape suivante lorsque vous modifierez votre monolithe pour le faire pointer vers le nouveau service "Orders" (Commandes).
Reconfigurer le monolithe
Vous avez supprimé le service "Orders" (Commandes) du monolithe, vous allez 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 microservices et vous les déployez séparément. Puisque les microservices s'exécutent sur un autre serveur, vous ne pouvez plus référencer l'URL des services sous la forme d'un chemin d'accès absolu. Vous devez router le trafic vers l'adresse du serveur du microservice "Orders" (Commandes). Pour ce faire, vous devrez arrêter le 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.
Vous devez modifier le fichier de configuration du 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 du microservice "Orders" (Commandes) :
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://<ADRESSE_IP_ORDERS>/api/orders
REACT_APP_PRODUCTS_URL=/service/products
Appuyez sur CTRL+O, sur ENTRÉE, puis sur CTRL+X pour enregistrer le fichier dans l'éditeur nano.
Testez le nouveau microservice en accédant à l'URL que vous venez de définir dans le fichier. La page Web doit renvoyer une réponse JSON de votre microservice "Orders" (Commandes).
Ensuite, recréez l'interface du monolithe puis répétez le processus de compilation pour créer le conteneur du monolithe et le redéployer sur le cluster GKE.
Recréez les fichiers de configuration du monolithe :
npm run build:monolith
Créez un conteneur Docker à l'aide de Cloud Build :
cd ~/monolith-to-microservices/monolith
gcloud builds submit --tag gcr.io/${GOOGLE_CLOUD_PROJECT}/monolith:2.0.0 .
Déployez le conteneur sur GKE :
kubectl set image deployment/monolith monolith=gcr.io/${GOOGLE_CLOUD_PROJECT}/monolith:2.0.0
Vérifiez que l'application appelle désormais le 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 :
Cliquez sur Check my progress (Vérifier ma progression) pour vérifier l'objectif.
Faire migrer les produits vers un microservice
Créer un microservice de produits ("Products")
Vous allez continuer à décomposer les services en faisant maintenant migrer le service "Products" (Produits). Suivez la même procédure que précédemment. Exécutez les commandes suivantes pour créer un conteneur Docker, le déployer et l'exposer via un service Kubernetes.
Créez un conteneur Docker à l'aide de Cloud Build :
cd ~/monolith-to-microservices/microservices/src/products
gcloud builds submit --tag gcr.io/${GOOGLE_CLOUD_PROJECT}/products:1.0.0 .
Déployez 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 du service "Products" (Produits) en procédant comme vous l'avez fait pour le service "Orders" (Commandes) :
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
Vous utiliserez cette adresse IP à l'étape suivante lorsque vous reconfigurerez le 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 du nouveau microservice "Products" (Produits) 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://<ADRESSE_IP_ORDERS>/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://<ADRESSE_IP_ORDERS>/api/orders
REACT_APP_PRODUCTS_URL=http://<ADRESSE_IP_PRODUCTS>/api/products
Appuyez sur CTRL+O, sur ENTRÉE, puis sur CTRL+X pour enregistrer le fichier.
Testez le nouveau microservice en accédant à l'URL que vous venez de définir dans le fichier. La page Web doit renvoyer une réponse JSON du microservice "Products" (Produits).
Ensuite, recréez l'interface du monolithe puis répétez le processus de compilation pour créer le conteneur du monolithe et le redéployer sur le cluster GKE. Pour ce faire, exécutez les commandes suivantes :
Recréez les fichiers de configuration du monolithe :
npm run build:monolith
Créez un conteneur Docker à l'aide de Cloud Build :
cd ~/monolith-to-microservices/monolith
gcloud builds submit --tag gcr.io/${GOOGLE_CLOUD_PROJECT}/monolith:3.0.0 .
Déployez le conteneur sur GKE :
kubectl set image deployment/monolith monolith=gcr.io/${GOOGLE_CLOUD_PROJECT}/monolith:3.0.0
Vérifiez que l'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 :
Cliquez sur Check my progress (Vérifier ma progression) pour vérifier l'objectif.
Faire 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 vous avez recréé le monolithe, vous avez mis à jour la configuration pour qu'elle pointe vers le monolithe. Maintenant, vous allez devoir utiliser la même configuration pour le 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, suivez 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éez 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éployez 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
Cliquez sur Check my progress (Vérifier ma progression) pour vérifier l'objectif.
Supprimer le monolithe
Maintenant que tous les services s'exécutent sous forme de microservices, vous pouvez supprimer l'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 vous assurer que tout fonctionne correctement, vérifiez que l'ancienne adresse IP de votre service "monolith" 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
La sortie obtenue devrait ressembler à ceci :
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.
Félicitations !
Vous avez décomposé votre application monolithique en microservices que vous avez déployés sur Google Kubernetes Engine.
Terminer votre quête
Cet atelier d'auto-formation fait partie de la quête Qwiklabs Website on Google Cloud. Une quête est une série d'ateliers associés qui constituent une formation. Inscrivez-vous à cette quête pour obtenir immédiatement les crédits associés à cet atelier si vous l'avez suivi. Découvrez les autres quêtes Qwiklabs disponibles.
Vous cherchez un atelier challenge pratique pour démontrer vos compétences et valider vos connaissances ? À la fin de cette quête, terminez cet atelier challenge supplémentaire pour recevoir un badge numérique Google Cloud exclusif.
Atelier suivant
Continuez sur votre lancée en regardant la vidéo d'une étude de cas portant sur l'hébergement d'applications Web évolutives sur Google Cloud, ou consultez nos suggestions de ressources :
-
Hébergement d'une application Web sur Google Cloud à l'aide de Compute Engine
-
Vidéo d'une étude de cas portant sur l'hébergement d'une application Web statique sur Google Cloud
Étapes suivantes et informations supplémentaires
- 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
- Bonnes pratiques concernant les microservices
Terminer l'atelier
Une fois l'atelier terminé, cliquez sur Terminer l'atelier. Votre compte et les ressources utilisées sont alors supprimés de la plate-forme d'atelier.
Si vous le souhaitez, vous pouvez noter l'atelier. Sélectionnez un nombre d'étoiles, saisissez un commentaire, puis cliquez sur Envoyer.
Voici à quoi correspond le nombre d'étoiles que vous pouvez attribuer à un atelier :
- 1 étoile = très insatisfait(e)
- 2 étoiles = insatisfait(e)
- 3 étoiles = ni insatisfait(e), ni satisfait(e)
- 4 étoiles = satisfait(e)
- 5 étoiles = très satisfait(e)
Si vous ne souhaitez pas donner votre avis, vous pouvez fermer la boîte de dialogue.
Pour soumettre des commentaires, suggestions ou corrections, veuillez accéder à l'onglet Assistance.
Dernière mise à jour du manuel : 26 mai 2020
Dernier test de l'atelier : 23 mars 2020
Copyright 2024 Google LLC Tous droits réservés. Google et le logo Google sont des marques de Google LLC. Tous les autres noms d'entreprises et de produits peuvent être des marques des entreprises auxquelles ils sont associés.