Parcours de formation : Transformer un monolithe en application GKE – Préparer l'application modulaire à la conteneurisation

Il s'agit du troisième tutoriel d'un parcours de formation qui vous explique comment modulariser et conteneuriser une application monolithique.

Le parcours de formation comprend les tutoriels suivants :

  1. Présentation
  2. Comprendre le monolithe
  3. Modulariser le monolithe
  4. Préparer l'application modulaire pour la conteneurisation (ce tutoriel)
  5. Conteneuriser l'application modulaire
  6. Déployer l'application dans un cluster GKE

Dans le tutoriel précédent, Modulariser le monolithe, vous avez vu comment diviser l'application Cymbal Books en modules Flask indépendants. Dans ce tutoriel, vous allez découvrir une modification unique à apporter à l'application modulaire pour la préparer à la conteneurisation.

Coûts

Vous pouvez suivre ce tutoriel sans frais. Toutefois, les étapes du dernier tutoriel de cette série entraînent des frais sur votre Google Cloud compte. Les coûts commencent lorsque vous activez GKE et déployez l'application Cymbal Books dans un cluster GKE. Ces coûts incluent les frais par cluster pour GKE, comme indiqué sur la page Tarifs, ainsi que les frais d'exécution des VM Compute Engine.

Pour éviter des frais inutiles, assurez-vous de désactiver GKE ou de supprimer le projet une fois ce tutoriel terminé.

Avant de commencer

Avant de commencer ce tutoriel, assurez-vous d'avoir suivi les tutoriels précédents de la série. Pour obtenir une présentation de l'ensemble de la série et des liens vers des tutoriels spécifiques, consultez Parcours de formation : Transformer un monolithe en application GKE – Présentation.

Si vous avez déjà suivi le premier tutoriel, vous avez cloné un dépôt GitHub. Les trois versions de l'application Cymbal Books se trouvent dans ce dépôt, dans les dossiers suivants :

  • monolith/
  • modular/
  • containerized/

Vérifiez que ces dossiers se trouvent sur votre machine avant de continuer.

Modifier le code modulaire

Dans le tutoriel précédent, vous avez appris que le module de la page d'accueil communique avec les autres modules. Il envoie des requêtes aux points de terminaison des autres modules pour récupérer les détails, les avis et les images des livres, puis présente ces données sur des pages HTML.

Dans le dossier modular/, les points de terminaison sont codés en dur dans home.py, à l'aide de localhost, comme suit :

BOOK_SERVICE_URL = "http://localhost:8081"     # Book details module listens on port 8081
REVIEW_SERVICE_URL = "http://localhost:8082"   # Book reviews module listens on port 8082
IMAGE_SERVICE_URL = "http://localhost:8083"    # Image module listens on port 8083

Ces URL fonctionnent lorsque tous les modules s'exécutent sur la même machine. Toutefois, dans un environnement Kubernetes, les modules peuvent être déplacés vers différentes machines pour gérer les défaillances ou équilibrer la charge, ce qui signifie que leurs adresses IP peuvent changer.

Pour s'assurer que le module de la page d'accueil peut toujours atteindre les autres modules, les URL doivent utiliser des noms de service Kubernetes au lieu de localhost. Un nom de service agit comme un alias que Kubernetes utilise pour acheminer les requêtes vers le module approprié, quel que soit l'endroit où il s'exécute. Par exemple, lorsque le module de la page d'accueil envoie une requête à http://book-details-service/book/1, Kubernetes permet de s'assurer que la requête atteint le module de détails du livre.

Vous n'avez pas besoin de mettre à jour ces URL vous-même. La version de l'application dans le dossier containerized/ inclut déjà cette modification : les URL localhost codées en dur ont été remplacées par des noms de service Kubernetes. Vous pouvez voir la version mise à jour dans containerized/home_app/home_app.py :

BOOK_SERVICE_URL = "http://book-details-service"
REVIEW_SERVICE_URL = "http://book-reviews-service"
IMAGE_SERVICE_URL = "http://images-service"

Cette mise à jour permet de s'assurer que l'application fonctionnera correctement lorsqu'elle s'exécutera dans un environnement Kubernetes.

Le fichier manifeste Kubernetes

Dans la section précédente, vous avez vu comment les points de terminaison des modules ont été mis à jour pour utiliser des noms de service Kubernetes. Vous définissez les noms de service dans le fichier manifeste Kubernetes.

Le fichier manifeste Kubernetes est un fichier de configuration qui définit le type de cluster Kubernetes que vous souhaitez créer pour héberger votre application modulaire. Le fichier manifeste est écrit au format YAML ou JSON. Vous y définissez des éléments tels que les services (pour le routage entre les modules), le nombre d'instances dupliquées de chaque module, ainsi que la quantité de processeur et de mémoire que chaque module est autorisé à utiliser.

Une série de tutoriels entiers pourrait être consacrée aux fichiers manifestes Kubernetes. Le fichier manifeste est complexe, car il définit tout ce qui concerne votre cluster Kubernetes : sa structure, son comportement et ses capacités. Dans ce tutoriel, vous ne verrez que comment les noms de service du fichier manifeste correspondent aux noms utilisés dans les points de terminaison des modules. Dans un tutoriel ultérieur, vous exécuterez la commande kubectl apply pour créer le cluster GKE en fonction de la configuration définie dans le fichier manifeste. Toutefois, dans ce tutoriel, vous ne ferez qu'examiner le fichier manifeste.

Afficher le fichier manifeste

Dans cette section, vous allez examiner comment les services sont définis dans un fichier manifeste Kubernetes qui a été écrit pour vous. Le fichier manifeste, qui est un fichier YAML, se trouve dans le dossier containerized/ du dépôt GitHub que vous avez cloné dans le premier tutoriel de cette série. Pour afficher une définition de service, procédez comme suit :

  1. Dans votre terminal, accédez au répertoire conteneurisé du dépôt cloné :

    cd containerized

  2. Dans un éditeur de texte, ouvrez le fichier manifeste Kubernetes :

    cat kubernetes_manifest.yaml

  3. Recherchez la définition de service pour le module book-details. Elle ressemble à l'exemple suivant :

    apiVersion: v1
kind: Service
metadata:
name: book-details-service
spec:
selector:
    app: book-details-app
ports:
    - protocol: TCP
    port: 80  # External traffic on port 80
    targetPort: 8080  # Targeting container port 8080
type: ClusterIP

Le nom de service book-details-service dans le fichier manifeste correspond au nom utilisé dans le point de terminaison du module : http://book-details-service. Lorsque votre application s'exécute dans Kubernetes, Kubernetes utilise ces noms de service pour acheminer les requêtes vers les modules appropriés.

Le fichier manifeste Kubernetes définit les fonctionnalités de votre cluster Kubernetes, y compris les services qui gèrent le routage des requêtes. Chaque module de votre application possède un service correspondant défini dans le fichier manifeste. En mettant à jour les URL dans le code modulaire pour qu'elles correspondent à ces noms de service, vous vous assurez que Kubernetes peut acheminer les requêtes vers les modules appropriés lorsque l'application s'exécute dans un cluster.

Résumé

Dans ce tutoriel, vous avez vu comment les URL du code modulaire ont été mises à jour pour utiliser des noms de service Kubernetes, tels que http://book-details-service. Ces noms de service permettent à Kubernetes d'acheminer les requêtes entre les modules, même lorsque leur emplacement dans le cluster change. Vous avez également examiné le fichier manifeste Kubernetes et vu comment les noms de service du code modulaire correspondent aux noms définis dans le fichier manifeste.

Étape suivante

Dans le tutoriel suivant, Conteneuriser l'application modulaire, vous apprendrez à conteneuriser un module en l'empaquetant dans ce que l'on appelle une image de conteneur. Vous verrez ensuite comment exécuter une image de conteneur en tant que conteneur, tester ses fonctionnalités et transférer l'image de conteneur vers Artifact Registry de Google.