Introduction
Juniper Café est prêt à lancer sa carte d’automne. Le site fonctionne, mais il affiche encore la sélection habituelle. Vous allez publier la nouvelle carte avec Kubernetes, conserver l’ancienne configuration et télécharger la carte réelle pour l’équipe au comptoir.
Vous devez déjà connaître les Pods, les Deployments, les Services, les labels et les bases de YAML. Le cluster, l’image de l’application et le site sont prêts ; vous n’avez besoin ni de programmer l’application ni de disposer d’un compte cloud. Ce lab présente la petite partie de Kustomize nécessaire pour donner à chaque configuration un nom fondé sur son contenu.
Utilisez Workspace pour les commandes, Café Menu pour Juniper et Reference Menu pour le café indépendant de la salle de lecture. Toutes ces entrées partagent une même VM de formation. Ne modifiez pas le café de référence, le code de l’application, le Service, le nombre de réplicas ni l’historique des versions fourni. Les 40 minutes estimées par l’auteur incluent la lecture et les erreurs courantes.
Préparer une version distincte de la carte
Dans cette étape, vous allez relier le site actuel à sa configuration et préparer un répertoire de publication sans modifier la carte en ligne.
Ouvrez Café Menu, sélectionnez Explore the menu et repérez Maple Latte. Il coûte actuellement $4.20 et porte la mention Not available today. Cold Brew est disponible. Ouvrez About this drink pour Oat Latte, puis utilisez Back to the menu. Ce sont de vraies pages servies par l’application préparée.
Passez à Reference Menu et sélectionnez Our menu. Il s’agit de Willow Reading Room, un service indépendant qui doit continuer à fonctionner. Passez à Workspace. Son répertoire de départ est /home/labex/project/cafe-menu ; confirmez-le avec pwd, qui affiche le répertoire courant :
pwd
Résultat attendu :
/home/labex/project/cafe-menu
Une ConfigMap Kubernetes stocke la configuration séparément de l’image de l’application. Un Pod fait référence à cette ConfigMap par son nom. Le processus de ce café lit le fichier de carte monté une seule fois, à son démarrage. Modifier la configuration ne provoque pas automatiquement le rechargement de la carte par ce processus déjà lancé.
Le répertoire starter préparé contient trois petits fichiers. ls les affiche :
ls starter
deployment.json kustomization.yaml menu.json
JSON est également un format valide pour les manifestes Kubernetes ; deployment.json est la définition du Deployment préparée. Vous conserverez les paramètres de l’application et modifierez les données distinctes de la carte.
Créez votre propre répertoire avec cp -r : cp copie et -r inclut le contenu d’un répertoire. La destination release n’existe pas encore :
cp -r starter release
Si vous exécutez cette commande deux fois par erreur, cp peut créer un répertoire imbriqué release/starter. Les trois fichiers requis doivent toujours se trouver directement dans release ; supprimez uniquement cette copie imbriquée accidentelle avec rm -r release/starter. Ne supprimez pas release, versions ni approved.
Lisez la configuration avec cat, qui affiche le contenu d’un fichier :
cat release/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
namespace: cafe-menu
resources:
- deployment.json
configMapGenerator:
- name: cafe-menu
files:
- menu.json
resources inclut le Deployment. configMapGenerator transforme menu.json en données de ConfigMap. Kustomize ajoute un suffixe dérivé du contenu et met à jour la référence du Deployment vers ce nom généré. Des données modifiées peuvent donc produire un nouveau modèle de Pod et un nouveau déploiement progressif, tandis que la ConfigMap précédente reste disponible. Le suffixe identifie le contenu ; il ne vous indique pas si les prix sont corrects.
Rédiger la carte d’automne approuvée
Dans cette étape, préparez la carte d’automne complète avant d’appliquer un changement à Kubernetes.
Restez dans Workspace. L’approbation de l’équipe au comptoir est enregistrée dans approved/menu.csv. CSV désigne des valeurs séparées par des virgules : la première ligne nomme les colonnes et chaque ligne suivante décrit une boisson. price_cents est un nombre entier de centimes ; 450 signifie donc $4.50. true et false indiquent si la boisson est disponible.
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
Ne modifiez pas Espresso ni Oat Latte. Cold Brew quitte la sélection du jour et Maple Latte devient disponible à $4.50. Le libellé de saison doit être Autumn at Juniper ; le nom du café, l’adresse, les horaires, les identifiants des articles et leurs descriptions restent inchangés.
Écrivez le JSON complet ci-dessous. JSON utilise des noms de propriétés entre guillemets, des virgules entre les entrées et des booléens en minuscules sans guillemets. L’expression shell cat > release/menu.json <<'EOF' écrit le texte délimité dans ce fichier. > remplace son contenu précédent ; les guillemets autour de EOF conservent le texte littéralement. Collez le bloc jusqu’à la dernière ligne EOF, qui doit occuper une ligne à elle seule :
cat > release/menu.json <<'EOF'
{
"name": "Juniper Café",
"season": "Autumn at Juniper",
"hours": "Mon–Sat · 08:00–17:00",
"address": "14 Willow Lane",
"items": [
{"id": "espresso", "name": "Espresso", "price_cents": 250, "available": true, "description": "A small, rich cup with a golden crema."},
{"id": "oat-latte", "name": "Oat Latte", "price_cents": 350, "available": true, "description": "Our espresso with smooth oat milk."},
{"id": "cold-brew", "name": "Cold Brew", "price_cents": 390, "available": false, "description": "Slow-steeped coffee, served over ice."},
{"id": "maple-latte", "name": "Maple Latte", "price_cents": 450, "available": true, "description": "Espresso, oat milk, and a little maple sweetness."}
]
}
EOF
Validez le JSON avant de l’utiliser. python3 -m json.tool lit le JSON et affiche une version indentée ; il ne modifie pas le fichier :
python3 -m json.tool release/menu.json
Un résultat valide contient les quatre boissons. L’outil peut afficher \u00e9 à la place de é ; c’est un échappement JSON, pas une modification du nom du café. Une virgule ou un guillemet manquant produit une erreur d’analyse avec un numéro de ligne et de colonne. Pour corriger cela, réécrivez le bloc complet ci-dessus, puis répétez cette validation. Un chemin incorrect produit une erreur de fichier introuvable ; exécutez pwd et revenez avec cd /home/labex/project/cafe-menu avant de réessayer.
Le site affiche encore la carte habituelle, car vous n’avez modifié que la source de votre publication. C’est normal.
Publier une nouvelle version de la configuration
Dans cette étape, générez les manifestes de la publication, appliquez-les et attendez que les deux réplicas du café utilisent la nouvelle configuration.
Restez dans Workspace. kubectl kustomize génère les manifestes d’un répertoire sans les appliquer. Examinez le nom de ConfigMap généré et la référence correspondante du Deployment :
kubectl kustomize release
La sortie inclut un nom de la forme cafe-menu-... et le même nom dans l’entrée volumes du Deployment appelée menu. Le suffixe exact dépend des données. Il s’agit d’un objet de configuration différent de celui de la carte habituelle.
Appliquez le répertoire avec kubectl apply -k. L’option -k demande à kubectl de générer les manifestes d’un répertoire Kustomize, au lieu de lire un manifeste avec -f :
kubectl apply -k release
La sortie attendue inclut :
configmap/cafe-menu-... created
deployment.apps/cafe configured
La seule création d’une ConfigMap ne prouve pas que l’application en cours d’exécution a changé. rollout status attend que le contrôleur du Deployment remplace les Pods. -n cafe-menu sélectionne l’espace de noms de cette leçon ; --timeout=120s limite l’attente :
kubectl rollout status deployment/cafe -n cafe-menu --timeout=120s
deployment "cafe" successfully rolled out
Si le délai expire, conservez l’environnement actuel et examinez-le avec les commandes suivantes. Une erreur d’image ou de conteneur apparaît dans l’état des Pods et les événements ; ne relancez pas la préparation et ne supprimez pas l’espace de noms :
kubectl get pods -n cafe-menu
kubectl describe deployment cafe -n cafe-menu
Après un déploiement progressif normal, examinez le Deployment actuel et ses ReplicaSets. Un ReplicaSet maintient un modèle de Pod particulier ; le Deployment conserve les anciens ReplicaSets comme historique des déploiements :
kubectl get replicasets -n cafe-menu -l app=cafe
Examinez le Deployment lui-même en précisant son nom :
kubectl get deployment cafe -n cafe-menu
Il doit afficher 2/2 réplicas prêts. Plusieurs objets de configuration restent présents ; l’application d’une nouvelle publication n’a pas écrasé l’ancienne carte. Listez-les :
kubectl get configmaps -n cafe-menu
Ne supprimez pas ces anciennes configurations. Un ancien ReplicaSet a besoin du nom de configuration exact auquel il fait référence si cette version est restaurée plus tard.
Vérifier le site et transmettre sa carte
Dans cette étape, vérifiez l’expérience réelle des clients et enregistrez la carte que l’équipe au comptoir utilisera.
Passez à Café Menu, sélectionnez Our menu et actualisez la page si elle est déjà ouverte. Maple Latte doit porter la mention Available today au prix de $4.50. Cold Brew doit porter la mention Not available today. Ouvrez la page de détail de Maple Latte, revenez avec Back to the menu, puis utilisez Visit us pour confirmer que l’adresse et les horaires restent accessibles.
Observez les badges de disponibilité et les prix : Cold Brew est indisponible et Maple Latte est disponible à $4.50.
Utilisez Download menu pour télécharger le véritable CSV complet. Ouvrez-le et comparez les quatre boissons au tableau approuvé de l’étape 2. Le téléchargement inclut les boissons indisponibles avec false, afin que le personnel puisse les distinguer des articles absents par erreur.
Passez à Reference Menu et confirmez que la carte habituelle de Willow Reading Room fonctionne toujours. Revenez ensuite à Workspace.
Vous pouvez aussi enregistrer le véritable téléchargement de Juniper dans votre espace de travail. curl interroge le point d’entrée local du navigateur, qui transmet la requête au véritable Service Kubernetes. --fail signale les erreurs HTTP ; --silent masque l’indicateur de progression ; --show-error garde les messages d’erreur visibles ; -o choisit le nom du fichier de sortie :
curl --fail --silent --show-error http://127.0.0.1:8081/menu.csv -o menu-handover.csv
Comparez le fichier reçu à l’approbation avec diff -u. L’option -u affiche les lignes voisines en cas de différence :
diff -u approved/menu.csv menu-handover.csv
L’absence de sortie signifie que les fichiers correspondent. Une différence est un indice utile : revenez à la source de la carte et au déploiement en cours, corrigez la cause, téléchargez à nouveau et recommencez la comparaison. Ne modifiez pas le CSV reçu pour masquer une erreur du site.
Vous disposez maintenant d’une carte utilisable, du véritable téléchargement destiné au personnel et d’un répertoire de publication qui reproduit la configuration en cours d’exécution. Conservez versions et les anciennes ConfigMaps intacts comme éléments de restauration dans cet environnement. La leçon suivante prépare son propre environnement indépendant.
Résumé
Vous avez préparé une publication complète de la carte, généré une ConfigMap nommée d’après son contenu et suivi le déploiement progressif du Deployment jusqu’aux deux réplicas de l’application. Vous avez vérifié de vraies pages et de vrais téléchargements, préservé le café de référence et les configurations précédentes, puis transmis le véritable CSV destiné au personnel.
Le prochain lab démarre dans un environnement distinct. Il reprend ces notions pour restaurer une carte dont l’application fonctionne correctement, mais dont les prix sont erronés.
