Cette page a été traduite par l'API Cloud Translation.

Parcours de formation : transformer un monolithe en application GKE : conteneuriser l'application modulaire

Standard

Il s'agit du quatriè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 :

Présentation
Comprendre le monolithe
Modulariser le monolithe
Préparer l'application modulaire pour la conteneurisation
Conteneuriser l'application modulaire (ce tutoriel)
Déployer l'application dans un cluster GKE

Dans le tutoriel précédent, Préparer l'application modulaire pour la conteneurisation, vous avez vu les modifications à apporter à la version modulaire de l'application Cymbal Books pour la préparer à la conteneurisation. Dans ce tutoriel, vous allez conteneuriser l'application.

Coûts

Vous pouvez suivre ce tutoriel sans frais. Toutefois, si vous suivez les étapes du prochain tutoriel de cette série, des frais seront facturés sur votre compteGoogle Cloud . Les coûts commencent lorsque vous activez GKE et déployez l'application Cymbal Books sur un cluster GKE. Ces coûts incluent les frais par cluster pour GKE, comme indiqué sur la page des tarifs, et 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.

Configurer votre environnement

Dans cette section, vous allez configurer un environnement dans lequel vous allez conteneuriser l'application modulaire. Plus précisément, vous allez effectuer les étapes suivantes :

Sélectionnez ou créez un Google Cloud projet.
Activer les API nécessaires
Connecter Cloud Shell à votre projet Google Cloud
Définir les variables d'environnement par défaut
Créer un dépôt dans Artifact Registry
Configurer Docker pour Artifact Registry
Obtenir le code du tutoriel

Sélectionner ou créer un projet Google Cloud

In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

Go to project selector
Make sure that billing is enabled for your Google Cloud project.

Activer les API nécessaires

Pour travailler avec des images de conteneurs et Kubernetes dans votre projet Google Cloud , vous devez activer les API suivantes :

API Artifact Registry : cette API active Artifact Registry, un service permettant de stocker et de gérer vos images de conteneurs.
API Kubernetes Engine : cette API permet d'accéder à GKE.

Pour activer ces API, consultez Activer les API dans la console Google Cloud .

Connecter Cloud Shell à votre projet Google Cloud

Maintenant que vous avez configuré votre projet Google Cloud , vous devez lancer une instance Cloud Shell et l'associer à votre projet Google Cloud. Cloud Shell est un outil de ligne de commande qui vous permet de créer et de gérer les ressources d'un projet directement depuis votre navigateur. Cloud Shell est préinstallé avec deux outils importants : la gcloud CLI et la CLI kubectl. Dans ce tutoriel, vous allez utiliser gcloud CLI pour interagir avec Google Cloud . Dans le tutoriel suivant, vous utiliserez la CLI kubectl pour gérer l'application Cymbal Books qui s'exécute sur GKE.

Pour associer une instance Cloud Shell à votre projet Google Cloud , procédez comme suit :

Accédez à la console Google Cloud :

Google Cloud console
Dans la console, cliquez sur le bouton Activer Cloud Shell :

Une session Cloud Shell s'ouvre dans un cadre situé en bas de la console.
Définissez votre projet par défaut dans Google Cloud CLI à l'aide de la commande suivante :
```
gcloud config set project PROJECT_ID
```
Remplacez PROJECT_ID par l'ID du projet que vous avez créé ou sélectionné dans la section précédente, Sélectionner ou créer un projet Google Cloud . Un ID de projet est une chaîne unique qui permet de différencier votre projet de tous les autres projets dans Google Cloud. Pour trouver l'ID du projet, accédez au sélecteur de projet. Sur cette page, vous pouvez consulter les ID de projet de chacun de vos projets Google Cloud.

Définir les variables d'environnement par défaut

Pour simplifier les commandes que vous exécuterez tout au long de ce tutoriel, vous allez maintenant définir des variables d'environnement dans Cloud Shell. Ces variables stockent des valeurs telles que l'ID de votre projet, la région du dépôt et le tag de l'image. Une fois ces variables définies, vous pouvez les réutiliser dans plusieurs commandes en faisant référence au nom de la variable (par exemple, $REPOSITORY_NAME) au lieu de saisir ou de remplacer les valeurs à chaque fois. Cette approche facilite le suivi du tutoriel et réduit le risque d'erreurs.

Pour configurer votre environnement avec Cloud Shell, procédez comme suit :

export PROJECT_ID=$(gcloud config get project)
export REPOSITORY_REGION=REPOSITORY_REGION
export REPOSITORY_NAME=REPOSITORY_NAME
export REPOSITORY_DESCRIPTION="REPOSITORY_DESCRIPTION"
export TAG=TAG

Remplacez les éléments suivants :

REPOSITORY_REGION : région dans laquelle vous souhaitez héberger votre dépôt Artifact Registry. Par exemple, us-central1 (Iowa), us-west1 (Oregon) ou europe-west1 (Belgique). Pour obtenir la liste complète des régions, consultez Régions et zones.
REPOSITORY_NAME : le nom de votre dépôt. Exemple :book-review-service-repo
REPOSITORY_DESCRIPTION : brève description de l'objectif du dépôt. Exemple :"Repository for storing Docker images for the book review service"
TAG : tag que vous souhaitez appliquer à une image. Un tag est un libellé que vous pouvez associer à une version spécifique d'une image de conteneur. Vous pouvez utiliser des conventions de nommage de tags comme celles-ci pour indiquer clairement les différentes versions d'une image :
- v1
- v1.2.3
- Un tag descriptif, tel que feature-x-dev
- Un tag qui indique l'environnement, tel que test

Créer un dépôt dans Artifact Registry

Ensuite, créez un dépôt dans Artifact Registry. Un dépôt est un emplacement de stockage où vous conservez les images de conteneurs. Lorsque vous créez une image de conteneur, vous avez besoin d'un emplacement pour la stocker afin de pouvoir la déployer ultérieurement sur un cluster Kubernetes. Artifact Registry vous permet de créer et de gérer ces dépôts dans votre projet Google Cloud .

Pour créer un dépôt dans Artifact Registry, exécutez la commande suivante :

gcloud artifacts repositories create ${REPOSITORY_NAME} \
    --repository-format=docker \
    --location=${REPOSITORY_REGION} \
    --description="${REPOSITORY_DESCRIPTION}"

Un résultat positif de la commande ressemble à ceci :

Waiting for operation [...] to complete...done.
Created repository [book-review-service-repo].

Configurer Docker pour Artifact Registry

Vous allez ensuite configurer Docker pour qu'il puisse communiquer de manière sécurisée avec le dépôt Artifact Registry deGoogle Cloud. Docker est un outil que vous pouvez utiliser pour empaqueter et exécuter des logiciels de manière cohérente dans différents environnements. Vous en saurez plus sur le fonctionnement de Docker dans la section suivante. Pour le moment, vous devez le configurer pour qu'il puisse se connecter à Artifact Registry.

Si vous ne configurez pas Docker de cette manière, vous ne pourrez pas envoyer les images de conteneur vers Artifact Registry (une tâche que vous effectuerez plus tard dans ce tutoriel). Vous ne pouvez pas non plus extraire les images de conteneurs d'Artifact Registry et les déployer sur un cluster GKE (une tâche que vous effectuerez dans le prochain tutoriel).

Pour configurer Docker afin qu'il s'authentifie auprès d'Artifact Registry, exécutez la commande suivante :

gcloud auth configure-docker ${REPOSITORY_REGION}-docker.pkg.dev

Obtenir le code du tutoriel

Maintenant que votre environnement Cloud Shell est configuré, vous devez télécharger le code du tutoriel dans Cloud Shell. Même si vous avez déjà cloné le dépôt sur votre ordinateur local, vous devez le cloner à nouveau ici sur votre instance Cloud Shell.

Bien qu'il soit possible de suivre ce tutoriel sur votre ordinateur local, vous devrez installer et configurer manuellement plusieurs outils tels que Docker, kubectl et gcloud CLI. Il est plus facile d'utiliser Cloud Shell, car il est préconfiguré avec tous ces outils.

Dans votre instance Cloud Shell, exécutez la commande suivante pour cloner le dépôt GitHub :

git clone https://github.com/GoogleCloudPlatform/kubernetes-engine-samples.git

Principes de base de la conteneurisation : images de conteneurs, conteneurs et Dockerfiles

Maintenant que vous avez configuré votre environnement et téléchargé le code conteneurisé, vous êtes prêt à conteneuriser l'application. Pour ce faire, vous devez utiliser un fichier Dockerfile afin d'empaqueter chaque module de Cymbal Books (page d'accueil, détails des livres, images et avis sur les livres) dans une image de conteneur. Lorsque l'application est déployée sur le cluster GKE, Kubernetes utilise ces images de conteneur pour créer des conteneurs en cours d'exécution dans le cluster.

Les sections suivantes expliquent ces concepts en détail.

Qu'est-ce que la conteneurisation ?

La conteneurisation regroupe un module et toutes ses dépendances, telles que les bibliothèques et les fichiers de configuration, dans une unité appelée image de conteneur. Les développeurs utilisent cette image de conteneur pour créer et exécuter des conteneurs dans n'importe quel environnement, qu'il s'agisse d'un ordinateur portable de développeur, d'un serveur de test ou d'un cluster Kubernetes de production.

Que sont les images de conteneur ?

Une image de conteneur contient tous les fichiers nécessaires à l'exécution d'une application. Ces fichiers incluent le code de l'application lui-même, les bibliothèques système, l'environnement d'exécution (par exemple, l'interpréteur Python), les données statiques et toutes les autres dépendances.

Dans ce tutoriel, vous allez créer une image de conteneur pour chaque module de l'application d'avis sur les livres.

Qu'est-ce qu'un conteneur ?

Un conteneur est un environnement isolé dans lequel s'exécute le code d'une image de conteneur. Vous pouvez créer des conteneurs de deux manières : en utilisant la commande docker run pour les tests pendant le développement ou en déployant des images de conteneurs sur un cluster Kubernetes.

Dans la version conteneurisée de l'application Cymbal Books, chaque module de l'application modulaire s'exécute dans son propre conteneur :

Le conteneur de la page d'accueil exécute le module de la page d'accueil et gère les requêtes adressées à /.
Le conteneur de détails du livre exécute le module de détails du livre et fournit des données pour les points de terminaison tels que /book/1 ou /book/3.
Le conteneur d'avis sur les livres exécute le module d'avis sur les livres et gère les requêtes vers des points de terminaison tels que /book/2/reviews.
Le conteneur d'images exécute le module d'images et diffuse les images de couverture de livres pour les points de terminaison tels que /images/fungi_frontier.jpg.

L'un des principaux avantages des conteneurs est que Kubernetes peut automatiquement en créer d'autres si nécessaire. Par exemple, si de nombreux utilisateurs lisent des critiques de livres, Kubernetes peut démarrer des conteneurs de critiques de livres supplémentaires pour gérer la charge.

Pour implémenter le scaling dans une application modulaire qui n'utilise pas de conteneurs, vous devez écrire du code personnalisé pour lancer de nouvelles instances d'un module et répartir le trafic entre elles. Avec Kubernetes, cette capacité de scaling est intégrée : vous n'avez pas besoin d'écrire de code de scaling personnalisé.

Que sont les fichiers Dockerfile ?

Un Dockerfile est un script qui définit comment empaqueter un module dans une image de conteneur. Dans ce tutoriel, vous n'avez pas besoin de créer de Dockerfiles. Ils sont déjà fournis dans le dépôt GitHub que vous avez cloné précédemment. Le répertoire de chaque module dans votre copie locale de kubernetes-engine-samples/quickstarts/monolith-to-microservices/containerized/ contient son propre fichier Dockerfile.

Par exemple, vous trouverez le Dockerfile du module home_app dans votre instance Cloud Shell à l'adresse kubernetes-engine-samples/quickstarts/monolith-to-microservices/containerized/home_app/Dockerfile. Voici à quoi ressemble ce fichier Dockerfile :

# Dockerfile for home_app
FROM python:3.9-slim #line 1
WORKDIR /app #line 2
COPY requirements.txt . #line 3
RUN pip install --no-cache-dir -r requirements.txt #line 4
COPY home_app.py . #line 5
COPY templates/ ./templates/ #line 6
COPY static/ ./static/ #line 7
CMD ["python", "home_app.py"] #line 8

Ce fichier Dockerfile effectue les étapes suivantes pour créer l'image de conteneur pour le module home_app :

Ligne 1 : FROM python:3.9-slim télécharge un interpréteur Python 3.9 et ses fichiers requis dans l'image de conteneur. Ces fichiers permettent au module de s'exécuter.
Ligne 2 : WORKDIR /app crée un répertoire nommé /app à l'intérieur du conteneur et définit ce répertoire comme répertoire de travail actuel. Toutes les commandes exécutées dans le conteneur le seront à partir de ce répertoire.
Lignes 3 et 4 : COPY requirements.txt . copie le fichier requirements.txt de votre ordinateur local dans le répertoire /app de l'image de conteneur. Le fichier requirements.txt liste toutes les bibliothèques Python dont home_app.py a besoin. La ligne RUN pip install installe ces bibliothèques dans l'image de conteneur.
Lignes 5 à 7 : les commandes COPY qui apparaissent sur ces lignes copient le code du module (home_app.py) et ses fichiers associés (modèles et éléments statiques) dans le répertoire /app de l'image de conteneur.
Ligne 8 : CMD spécifie la commande par défaut que Docker exécute au démarrage du conteneur. Dans ce fichier Dockerfile, CMD ["python", "home_app.py"] indique à Docker d'utiliser l'interpréteur Python pour exécuter le module home_app.py automatiquement au lancement du conteneur.

Comment la conteneurisation peut renforcer l'isolation des données

Les lignes 5 à 7 du Dockerfile, décrites dans la section précédente, montrent comment la conteneurisation peut appliquer une isolation des données plus stricte que la version modularisée de l'application. Dans un tutoriel précédent, dans la section N'autoriser chaque module à accéder qu'aux données dont il a besoin, vous avez appris que la version modularisée de l'application organisait les données dans des répertoires distincts, mais que les modules partageaient toujours le même système de fichiers et pouvaient potentiellement accéder aux données des autres.

Ici, dans la version conteneurisée de l'application, le conteneur de chaque module n'inclut que les fichiers nécessaires. Par exemple, si le module home_app n'a pas besoin d'accéder aux données des avis sur les livres, ces données n'existent tout simplement pas dans le conteneur home_app. Par défaut, un conteneur ne peut pas accéder aux fichiers d'un autre conteneur, sauf s'il est explicitement configuré pour le faire. Cela permet de s'assurer que chaque module est entièrement isolé et d'éviter tout accès accidentel ou non autorisé aux données.

Dans la section suivante, vous verrez comment la commande docker build prend un fichier Dockerfile en entrée et suit les instructions de ce fichier pour créer une image de conteneur.

Créer des images de conteneur à l'aide de Docker

Dans cette section, vous allez créer des images de conteneur Docker pour chacun des modules d'avis sur les livres et les transférer vers votre dépôt Artifact Registry. Vous utiliserez ces images de conteneur dans un prochain tutoriel pour déployer et exécuter l'application exemple Cymbal Books dans Kubernetes.

Accédez au répertoire racine de l'application conteneurisée :

cd kubernetes-engine-samples/quickstarts/monolith-to-microservices/containerized/

Créez les images de conteneur à l'aide de la commande docker build :

docker build -t ${REPOSITORY_REGION}-docker.pkg.dev/${PROJECT_ID}/${REPOSITORY_NAME}/home-app:${TAG} ./home_app
docker build -t ${REPOSITORY_REGION}-docker.pkg.dev/${PROJECT_ID}/${REPOSITORY_NAME}/book-details-app:${TAG} ./book_details_app
docker build -t ${REPOSITORY_REGION}-docker.pkg.dev/${PROJECT_ID}/${REPOSITORY_NAME}/book-reviews-app:${TAG} ./book_reviews_app
docker build -t ${REPOSITORY_REGION}-docker.pkg.dev/${PROJECT_ID}/${REPOSITORY_NAME}/images-app:${TAG} ./images_app

Affichez les images de conteneur créées dans votre instance Cloud Shell :
```
docker images
```
Vérifiez que les images suivantes apparaissent dans la liste :
- home-app
- book-details-app
- book-reviews-app
- images-app
Si les quatre images sont listées, vous avez créé les images de conteneur avec succès.

Tester des conteneurs dans Cloud Shell

Pour vérifier que les images de conteneur sont correctement créées, vous pouvez les exécuter en tant que conteneurs et tester leurs points de terminaison dans Cloud Shell.

Les conteneurs book_details_app, book_reviews_app et images_app peuvent être testés individuellement, car ils n'ont pas besoin de communiquer entre eux. Toutefois, il est difficile de tester le conteneur home_app à l'aide de Docker, car home_app est configuré pour trouver les autres conteneurs qui utilisent des noms de service tels que http://book-details-service:8081.

Bien qu'il soit possible de tester le conteneur home_app en recherchant l'adresse IP de chaque conteneur et en configurant home_app pour qu'il les utilise au lieu des noms de service, cette approche demande beaucoup d'efforts. Il est préférable de différer le test du conteneur home_app jusqu'à ce que vous ayez déployé l'application sur un cluster Kubernetes. Une fois l'application sur le cluster, vous pouvez déterminer si le module Home fonctionne correctement.

Pour tester les conteneurs, procédez comme suit :

Démarrez les conteneurs book_details_app, book_reviews_app et images_app :

docker run -d -p 8081:8080 ${REPOSITORY_REGION}-docker.pkg.dev/${PROJECT_ID}/${REPOSITORY_NAME}/book-details-app:${TAG}
docker run -d -p 8082:8080 ${REPOSITORY_REGION}-docker.pkg.dev/${PROJECT_ID}/${REPOSITORY_NAME}/book-reviews-app:${TAG}
docker run -d -p 8083:8080 ${REPOSITORY_REGION}-docker.pkg.dev/${PROJECT_ID}/${REPOSITORY_NAME}/images-app:${TAG}

Vérifiez que les conteneurs sont en cours d'exécution en listant tous les conteneurs actifs :

docker ps

Le résultat de cette commande doit afficher trois conteneurs en cours d'exécution, avec l'état Up :

CONTAINER ID   IMAGE                PORTS                        STATUS
a1b2c3d4e5f6   REGION/.../details   0.0.0.0:8081->8080/tcp       Up
g7h8i9j0k1l2   REGION/.../reviews   0.0.0.0:8082->8080/tcp       Up
m3n4o5p6q7r8   REGION/.../images    0.0.0.0:8083->8080/tcp       Up

Pour tester les points de terminaison du conteneur book_details_app, utilisez les commandes curl suivantes :

curl http://localhost:8081/books
curl http://localhost:8081/book/1
curl http://localhost:8081/book/2
curl http://localhost:8081/book/3

Chacune de ces commandes renvoie des données au format JSON. Par exemple, le résultat de la commande curl http://localhost:8081/book/1 se présente comme suit :

{"author":"Aria Clockwork","description":"In a world where time is a tangible substance, a young clockmaker discovers she can manipulate the fabric of time itself, leading to unforeseen consequences in her steampunk-inspired city.","id":1,"image_url":"zephyrs_timepiece.jpg","title":"Zephyr's Timepiece","year":2023}

Récupérez les avis sur les livres à partir du conteneur book_reviews_app à l'aide de la commande curl :
```
curl http://localhost:8082/book/1/reviews
```
Cette commande renvoie une liste de 20 avis sur le livre 1 au format JSON. Voici un exemple d'avis de la liste :
```
{
"content": "The concept of time as a tangible substance is brilliantly explored in 'Zephyr's Timepiece'.",
"rating": 5
}
```
Testez le conteneur images_app :
1. Cliquez sur le bouton **Web Preview**.
2. Sélectionnez Modifier le port et saisissez 8083. Une fenêtre de navigateur s'ouvre avec une URL semblable à celle-ci :
```
https://8083-your-instance-id.cs-your-region.cloudshell.dev/?authuser=0
```
3. Supprimez ?authuser=0 à la fin de l'URL et ajoutez le chemin d'accès à un fichier image, tel que /images/fungi_frontier.jpg. En voici un exemple :
```
https://8083-your-instance-id.cs-your-region.cloudshell.dev/images/fungi_frontier.jpg
```
  L'image de couverture du livre Fungi Frontier doit s'afficher dans votre navigateur.
Après les tests, arrêtez les conteneurs pour libérer des ressources :
1. Répertoriez les conteneurs en cours d'exécution et recherchez leurs ID :
```
docker ps
```
2. Arrêtez chaque conteneur :
```
docker stop CONTAINER_ID
```
  Remplacez CONTAINER_ID par l'ID du conteneur que vous souhaitez arrêter.

Transférer les images de conteneur vers Artifact Registry

Avant de pouvoir déployer votre application sur un cluster Kubernetes, les images de conteneurs doivent être stockées dans un emplacement auquel le cluster peut accéder. À cette étape, vous allez transférer les images vers le dépôt Artifact Registry que vous avez créé précédemment. Dans le prochain tutoriel, vous déploierez ces images du dépôt Artifact Registry vers un cluster GKE :

Pour transférer vos images de conteneurs vers Artifact Registry, exécutez les commandes suivantes :

docker push ${REPOSITORY_REGION}-docker.pkg.dev/${PROJECT_ID}/${REPOSITORY_NAME}/home-app:${TAG}
docker push ${REPOSITORY_REGION}-docker.pkg.dev/${PROJECT_ID}/${REPOSITORY_NAME}/book-details-app:${TAG}
docker push ${REPOSITORY_REGION}-docker.pkg.dev/${PROJECT_ID}/${REPOSITORY_NAME}/book-reviews-app:${TAG}
docker push ${REPOSITORY_REGION}-docker.pkg.dev/${PROJECT_ID}/${REPOSITORY_NAME}/images-app:${TAG}

Après avoir transféré les images, vérifiez qu'elles ont bien été importées en les listant :

gcloud artifacts docker images list ${REPOSITORY_REGION}-docker.pkg.dev/${PROJECT_ID}/${REPOSITORY_NAME}

La sortie obtenue doit ressembler à ceci :

Listing items under project ${PROJECT_ID}, location ${REPOSITORY_REGION}, repository ${REPOSITORY_NAME}.

IMAGE: ${REPOSITORY_REGION}-docker.pkg.dev/${PROJECT_ID}/${REPOSITORY_NAME}/book-details-app
DIGEST: sha256:f7b78f44d70f2eedf7f7d4dc72c36070e7c0dd05daa5f473e1ebcfd1d44b95b1
CREATE_TIME: 2024-11-14T00:38:53
UPDATE_TIME: 2024-11-14T00:38:53
SIZE: 52260143

IMAGE: ${REPOSITORY_REGION}-docker.pkg.dev/${PROJECT_ID}/${REPOSITORY_NAME}/book-reviews-app
DIGEST: sha256:875ac8d94ef54db2ff637e49ad2d1c50291087623718b854a34ad657748fac86
CREATE_TIME: 2024-11-14T00:39:04
UPDATE_TIME: 2024-11-14T00:39:04
SIZE: 52262041

IMAGE: ${REPOSITORY_REGION}-docker.pkg.dev/${PROJECT_ID}/${REPOSITORY_NAME}/home-app
DIGEST: sha256:70ddc54ffd683e2525d87ee0451804d273868c7143d0c2a75ce423502c10638a
CREATE_TIME: 2024-11-14T00:33:56
UPDATE_TIME: 2024-11-14T00:33:56
SIZE: 52262412

IMAGE: ${REPOSITORY_REGION}-docker.pkg.dev/${PROJECT_ID}/${REPOSITORY_NAME}/images-app
DIGEST: sha256:790f0d8c2f83b09dc3b431c4c04d7dc68254fecc76c48f00a83babc2a5dc0484
CREATE_TIME: 2024-11-14T00:39:15
UPDATE_TIME: 2024-11-14T00:39:15
SIZE: 53020815

Le résultat inclut les informations suivantes pour chaque image :

IMAGE : chemin d'accès au dépôt et nom de l'image.
DIGEST : identifiant unique de l'image.
CREATE_TIME ou UPDATE_TIME : date de création ou de dernière modification de l'image.
SIZE : taille de l'image en octets.

Mettre à jour le fichier manifeste Kubernetes avec les chemins d'accès aux images de conteneurs

Comme vous l'avez appris dans le tutoriel précédent, Préparer l'application modulaire pour la conteneurisation, un fichier manifeste Kubernetes est un fichier YAML qui définit la façon dont votre application s'exécute dans un cluster Kubernetes. Elle inclut des informations telles que les suivantes :

Les modules de votre application (par exemple,home-app, book-details-app)
Chemins d'accès aux images de conteneurs
Détails de la configuration, tels que les limites de ressources
Définitions de service pour le routage des requêtes entre les modules

Dans cette section, vous allez mettre à jour le même fichier manifeste que celui que vous avez examiné dans le tutoriel précédent. Ce fichier est kubernetes-manifest.yaml et contient des valeurs d'espace réservé pour les chemins d'image. Vous devez remplacer ces espaces réservés par les chemins d'accès réels aux images de conteneurs que vous avez transférées vers votre dépôt Artifact Registry dans la section précédente.

Pour mettre à jour le fichier manifeste Kubernetes kubernetes-manifest.yaml, procédez comme suit :

Dans Cloud Shell, accédez au répertoire containerized/, qui contient le fichier manifeste Kubernetes kubernetes-manifest.yaml :
```
cd kubernetes-engine-samples/quickstarts/monolith-to-microservices/containerized/
```
Ouvrez le fichier kubernetes-manifest.yaml dans un éditeur de texte :
```
vim kubernetes-manifest.yaml
```
Recherchez les champs image contenant des espaces réservés tels que :
```
image: REPOSITORY_REGION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/home-app:TAG
```
Remplacez chaque espace réservé par les chemins d'accès réels aux images de conteneur que vous avez transférées vers Artifact Registry :
- REPOSITORY_REGION : région que vous avez spécifiée lorsque vous avez créé un dépôt dans Artifact Registry.
- PROJECT_ID : ID de votre projet Google Cloud , que vous trouverez sur la page du sélecteur de projet.
- REPOSITORY_NAME : nom de votre dépôt, que vous avez spécifié lorsque vous avez créé un dépôt dans Artifact Registry. Par exemple, book-review-service-repo.
- TAG : tag que vous avez choisi lorsque vous avez créé les images de conteneur.
Voici à quoi un chemin d'accès peut ressembler après ces remplacements :
```
image:us-west1-docker.pkg.dev/your-project-id/book-review-service-repo/home-app:v1
```
Mettez à jour les chemins d'accès pour toutes les images de conteneur :
- home-app
- book-details-app
- book-reviews-app
- images-app
Une fois les chemins d'accès mis à jour, enregistrez le fichier manifeste et fermez l'éditeur. Par exemple, si vous utilisez vim, appuyez sur Échap pour passer en mode commande, saisissez wq, puis appuyez sur Entrée pour enregistrer et quitter.

Votre fichier manifeste Kubernetes est désormais configuré pour déployer les images de conteneur de votre dépôt Artifact Registry sur un cluster Kubernetes.

Résumé

Dans ce tutoriel, vous avez préparé l'application modulaire Cymbal Books pour le déploiement sur un cluster Kubernetes en effectuant les tâches suivantes :

Configurez un projet Google Cloud et configurez Cloud Shell pour votre environnement.
Examiné les fichiers Dockerfile fournis pour chaque module d'application.
Créez des images de conteneur pour les modules d'application à l'aide de Docker.
Testé les conteneurs dans Cloud Shell pour vérifier leur fonctionnalité.
Transférez les images de conteneurs vers Artifact Registry pour les stocker.
Mise à jour du fichier manifeste Kubernetes pour utiliser les chemins d'accès aux images de conteneurs appropriés depuis Artifact Registry.

Étapes suivantes

Dans le tutoriel suivant, Déployer l'application dans un cluster GKE, vous déployez l'application en conteneur dans un cluster GKE.