Introduction
Juniper Café répond aux requêtes, mais sa dernière carte facture $35.00 pour un Oat Latte. Un Pod en bon état peut tout de même servir des données métier incorrectes. Vous allez restaurer la carte d’automne approuvée tout en préservant le café, ses versions précédentes et le service indépendant de la salle de lecture.
Cet environnement neuf possède son propre historique de publications préparé. Il n’utilise aucun fichier ni processus du lab précédent. Vous devez avoir terminé le lab sur la carte saisonnière : cette leçon reprend son format de carte, ses ConfigMaps générées, son Deployment et ses vérifications de téléchargement, puis introduit le choix d’une révision et la restauration. La durée de 35 minutes est une estimation de l’auteur, pas un temps mesuré auprès de débutants.
Restaurer la révision approuvée
Dans cette étape, utilisez la carte réelle et l’historique du Deployment pour choisir et restaurer la version d’automne approuvée.
Ouvrez Café Menu, sélectionnez Explore the menu et repérez Oat Latte. Son prix actuel de $35.00 est erroné, même si le site et les pages de détail des boissons se chargent. Passez à Workspace, dont le répertoire de départ est /home/labex/project/cafe-menu.
Lisez le tableau approuvé complet de l’équipe au comptoir et le libellé de saison. Comme dans le lab précédent, les prix sont des nombres entiers de centimes ; 350 signifie $3.50 :
cat approved/menu.csv
id,name,price_cents,available
espresso,Espresso,250,true
oat-latte,Oat Latte,350,true
cold-brew,Cold Brew,390,false
maple-latte,Maple Latte,450,true
cat approved/season.txt
Autumn at Juniper
Un déploiement progressif réussi signifie que Kubernetes a atteint l’état demandé pour les Pods. Il ne valide pas tous les prix de la carte. Vérifiez le Deployment en bon état, puis listez ses révisions. rollout history lit les ReplicaSets conservés ; le texte indiquant la cause du changement aide à identifier chaque publication préparée :
kubectl get deployment cafe -n cafe-menu
kubectl rollout history deployment/cafe -n cafe-menu
L’historique contient les révisions everyday, autumn et misprint, dans cet ordre. Les numéros de révision appartiennent à ce Deployment dans cet environnement neuf ; ne considérez pas un numéro comme un nom de version universel.
Les versions enregistrées complètes sont également disponibles. Comparez l’ancienne carte habituelle à la carte d’automne approuvée :
cat versions/everyday/menu.json
cat versions/autumn/menu.json
La version habituelle a un prix correct pour Oat Latte, mais propose encore Cold Brew et ne propose pas Maple Latte. Restaurer n’importe quelle ancienne publication serait donc incorrect. La version d’automne correspond à toutes les valeurs approuvées et au libellé de saison.
Examinez la révision 2, la révision d’automne préparée dans cet environnement. --revision=2 demande les détails de son modèle de Pod :
kubectl rollout history deployment/cafe -n cafe-menu --revision=2
Repérez la référence à la ConfigMap générée dans le volume menu. Ce modèle enregistré peut démarrer de nouveaux Pods avec cette ancienne configuration exacte, car la ConfigMap existe toujours.
Restaurez cette révision. rollout undo modifie le Deployment pour utiliser le modèle de Pod antérieur sélectionné ; --to-revision=2 sélectionne explicitement celui qui est approuvé :
kubectl rollout undo deployment/cafe -n cafe-menu --to-revision=2
Attendez les deux réplicas restaurés :
kubectl rollout status deployment/cafe -n cafe-menu --timeout=120s
deployment "cafe" successfully rolled out
Passez à Café Menu, sélectionnez Our menu et actualisez si nécessaire. Confirmez qu’Oat Latte coûte $3.50, que Maple Latte est disponible à $4.50 et que Cold Brew est indisponible. Si le délai expire, utilisez la démarche de diagnostic avec kubectl get pods et kubectl describe deployment enseignée dans le lab précédent ; ne réinitialisez pas l’espace de noms.
Comparez les quatre fiches, y compris celle de Cold Brew, indisponible.
Une limite importante : l’annulation restaure le modèle de Pod, y compris le nom de sa configuration. Elle ne restaure pas arbitrairement le contenu antérieur d’une ConfigMap modifiée sur place. Ne modifiez aucune des configurations générées conservées.
Aligner la publication enregistrée
Dans cette étape, faites en sorte que votre publication enregistrée reproduise l’application restaurée en cours d’exécution.
Revenez à Workspace. Un retour arrière sur le système en cours d’exécution ne modifie pas les fichiers locaux. Le répertoire release contient encore la version candidate incorrecte ; l’appliquer maintenant rétablirait le mauvais prix. Lisez ce fichier avant de le remplacer :
cat release/menu.json
Il contient toujours 3500 centimes pour Oat Latte. Copiez la carte d’automne approuvée et la définition du Deployment dans votre publication de travail. Chaque cp remplace uniquement le fichier de destination nommé. Ne modifiez pas les répertoires des versions d’origine :
cp versions/autumn/menu.json release/menu.json
cp versions/autumn/deployment.json release/deployment.json
Le fichier du Deployment porte aussi l’annotation approuvée indiquant la cause du changement. Votre fichier kustomization.yaml existant conserve le même générateur et le même espace de noms. Générez à nouveau les manifestes de la publication :
kubectl kustomize release
Le nom de configuration généré doit correspondre à la référence du modèle d’automne restauré. Aucune nouvelle version des données n’est nécessaire, car le contenu de la carte est identique octet pour octet. Appliquez la source ainsi alignée :
kubectl apply -k release
kubectl rollout status deployment/cafe -n cafe-menu --timeout=120s
Le déploiement progressif se termine en conservant la carte approuvée. Une nouvelle application des manifestes préserve désormais la restauration au lieu de l’annuler. Conservez tout le répertoire release : le Deployment, le fichier de carte et la configuration du générateur fonctionnent ensemble. Si vous avez copié depuis un mauvais chemin, pwd et ls versions/autumn vous aident à retrouver les fichiers fournis ; répétez les deux copies précises au lieu de modifier l’historique conservé.
Livrer la carte restaurée
Dans cette étape, terminez avec un véritable téléchargement de la carte et confirmez que le café non concerné fonctionne toujours.
Passez à Café Menu. Depuis Our menu, ouvrez le lien About this drink d’Oat Latte, confirmez le prix corrigé de $3.50 sur la page de détail, puis revenez avec Back to the menu. Ouvrez Visit us et confirmez l’adresse et les horaires. Utilisez Download menu pour télécharger la véritable carte complète.
Passez à Reference Menu et sélectionnez Our menu. Willow Reading Room doit toujours afficher sa sélection habituelle ; réparer Juniper ne doit pas modifier ce service indépendant.
Revenez à Workspace. Enregistrez le téléchargement réel avec les mêmes options curl que dans le premier lab :
curl --fail --silent --show-error http://127.0.0.1:8081/menu.csv -o menu-handover.csv
Comparez-le au tableau approuvé :
diff -u approved/menu.csv menu-handover.csv
L’absence de sortie signifie que le téléchargement complet correspond. Si des différences apparaissent, utilisez les lignes réelles pour distinguer une mauvaise version restaurée d’une source enregistrée obsolète. Corrigez la publication, attendez le déploiement progressif et téléchargez à nouveau ; ne modifiez pas à la main le CSV reçu.
Listez les configurations pour confirmer que les anciennes versions restent disponibles :
kubectl get configmaps -n cafe-menu
La restauration est terminée lorsque le café en cours d’exécution, la source réutilisable et le véritable téléchargement destiné au personnel concordent. Les versions précédentes de la source et les objets de configuration générés restent intacts.
Résumé
Vous avez distingué une application en bon état d’une carte correcte, choisi une révision à partir de l’ensemble des éléments métier et restauré sa référence de configuration conservée. Vous avez aussi aligné la publication locale pour qu’une application ultérieure des manifestes préserve la restauration, puis vérifié de vraies pages et le téléchargement réel de la carte sans modifier le service de référence.
Le défi indépendant change le café, les relations entre les éléments de la carte et la version approuvée. Il utilise les mêmes méthodes de configuration, de déploiement progressif et de transmission.
