Publier la mise à jour d’un site événementiel

Introduction

Common Ground est un site communautaire de démonstration. Les visiteurs consultent Linux Evening, ouvrent sa fiche et lisent les modalités d'inscription. La prochaine version déplace l'événement de Room A à Community Hall. Vous devez publier cette mise à jour préparée sans perdre la version actuelle.

Vous distinguerez une version installée d'une version en service, sélectionnerez la mise à jour et testerez le site réel. L'application et l'outil de publication sont fournis ; vous n'avez ni code à écrire ni Nginx à configurer. Des notions de terminal suffisent. Tous les événements et adresses sont fictifs.

Chaque TP démarre dans son propre environnement préparé. Les onglets sont prêts à l'emploi.

Découvrez le site et préparez la mise à jour

Vous allez établir le fonctionnement normal du site et installer une nouvelle version sans modifier ce que voient les visiteurs. Commencez dans Website.

Établir le fonctionnement normal

L'accueil présente Common Ground et affiche Linux Evening sous On the horizon. L'événement indique actuellement Location: Room A. Faites défiler jusqu'en bas : le petit pied de page indique Release: event-v1. Une version correspond à un ensemble précis de fichiers du site sauvegardés.

Dans Website, cliquez sur la ligne Linux Evening. La fiche indique mardi à 18 h et Room A. Ouvrez Registration instructions ; cette page explique la procédure de démonstration par courriel. Aucune inscription réelle n'est nécessaire. Cliquez sur le logo COMMON GROUND en haut pour revenir à l'accueil dans le même onglet.

Ce sont les parcours à préserver. La page d'accueil ne représente pas tout le service.

Préparer une copie séparée

Passez dans Workstation. Le terminal se trouve déjà dans /home/labex/project/website-release, l'espace de publication fourni. ls liste les noms du répertoire courant :

ls

Vous verrez packages, releases, current et release.sh. packages contient les versions fournies à installer, et releases les versions installées. current sélectionne celle que reçoivent les visiteurs ; vous l'examinerez à l'étape suivante.

release.sh est un petit outil fourni. bash exécute ce script ; les mots qui suivent son nom choisissent une action et, si nécessaire, une version. Vous utilisez cet outil, sans devoir écrire du code Bash.

bash release.sh help

Lisez l'aide succincte. install copie un paquet dans son propre répertoire ; deploy sélectionne une version pour le site ; rollback sélectionne une version déjà installée. Aucune de ces actions ne détermine si les pages remplissent leur fonction.

Listez les versions fournies :

bash release.sh list

Elles se nomment event-v1 et event-v2. Installez la mise à jour :

bash release.sh install event-v2

Sortie attendue :

Installed event-v2. The current website was not changed.

Vérifiez l'existence des deux répertoires installés. Ajouter releases indique à ls quel répertoire lister :

ls releases

Vous devez trouver event-v1 et event-v2. Installer une copie séparée conserve l'ancienne version. Cela ne publie pas la mise à jour.

Revenez dans Website et rechargez la page. Le lieu reste Room A et le pied de page indique toujours event-v1. C'est normal : l'étape suivante sélectionnera la mise à jour.

Sélectionnez et publiez la mise à jour

Vous allez changer la version sélectionnée du site tout en conservant sa version de restauration. Commencez dans Workstation.

Comprendre la sélection

Un lien symbolique est une référence du système de fichiers vers un autre emplacement. Ici, current pointe vers le répertoire d'une version installée. Nginx, le serveur web fourni, lit les fichiers du site par ce lien.

readlink affiche la cible d'un lien symbolique :

readlink current

Sortie attendue :

releases/event-v1

Ce chemin relatif désigne le répertoire event-v1 dans le répertoire releases de cet espace de travail. Chaque répertoire contient les pages HTML, les styles CSS locaux, l'illustration locale et un petit fichier de version. L'ensemble forme une version complète du site.

cat affiche un fichier. Confirmez l'identité de la version de restauration avant publication :

cat releases/event-v1/version.txt

La commande affiche event-v1. Gardez ce répertoire complet. Le plan consiste à le sélectionner de nouveau si les contrôles de la mise à jour échouent ; le reconstruire ou le supprimer compromettrait ce plan.

Publier la version installée

Sélectionnez la mise à jour :

bash release.sh deploy event-v2

Sortie attendue :

Selected event-v2. The server reports:
event-v2
Selection finished. Check the required pages before accepting this release.

L'outil réutilise le répertoire installé, bascule current au moyen d'un lien temporaire et d'un renommage, puis effectue une véritable requête de version. Il évite ainsi d'écraser les anciens fichiers. Cela ne prouve pas que toutes les pages fonctionnent et ne garantit pas qu'une session entière du navigateur change de version d'un seul coup.

Examinez la sélection :

readlink current

La commande affiche maintenant releases/event-v2.

Passez dans Website. Si une autre page est ouverte, cliquez sur COMMON GROUND pour revenir à l'accueil, puis rechargez. Sous On the horizon, la session indique Location: Community Hall. Le pied de page identifie event-v2.

Le nouveau lieu et le pied de page confirment le changement. Vous devez encore vérifier les parcours importants avant d'accepter cette version.

Validez le site et préservez la possibilité de restauration

Vous allez vérifier la nouvelle version comme visiteur et comme client HTTP, puis confirmer que l'ancienne reste disponible. Commencez dans Website.

Suivre les parcours utilisateur

Cliquez sur Linux Evening. La barre latérale de la fiche doit afficher Community Hall, et non Room A. Ouvrez Registration instructions. La page doit présenter les étapes de participation et events@example.test, pas un écran de page introuvable.

Cliquez sur COMMON GROUND dans Website pour revenir à l'accueil.

Vérifier les réponses HTTP réelles

Passez dans Workstation. HTTP est le protocole de requêtes et de réponses utilisé par ce site. Une requête désigne un chemin, comme /registration.html ; le serveur renvoie un statut et un contenu. 200 signifie que la réponse demandée a réussi. 404 signifie que la page demandée est introuvable.

curl envoie une requête. -sS masque la progression, mais affiche les erreurs de connexion. -o /dev/null écarte le corps de la réponse ; /dev/null est la destination de suppression du système. -w affiche le format qui suit. Les apostrophes gardent ce format groupé, %{http_code} choisit le statut et \n termine la ligne de sortie.

127.0.0.1 désigne cet environnement ; le port 8081 correspond au site préparé. Utilisez cette adresse dans Workstation, pas dans le terminal de votre ordinateur. La / finale demande l'accueil.

Vérifiez l'accueil :

curl -sS -o /dev/null -w '%{http_code}\n' http://127.0.0.1:8081/

Le résultat est 200.

Vérifiez séparément la fiche et les instructions d'inscription :

curl -sS -o /dev/null -w '%{http_code}\n' http://127.0.0.1:8081/events/linux-evening.html

curl -sS -o /dev/null -w '%{http_code}\n' http://127.0.0.1:8081/registration.html

Les deux réponses doivent être 200. Vérifier le contenu dans Website compte aussi : une réponse 200 contenant la mauvaise page n'est pas un succès.

Vous pouvez également demander la petite réponse de version sans écarter son corps :

curl -sS http://127.0.0.1:8081/version.txt

Elle affiche event-v2. C'est un indice utile, mais une étiquette de version ne remplace pas les vérifications des pages et des liens.

Préserver la possibilité de restauration

La version d'origine doit rester intacte :

cat releases/event-v1/version.txt

La commande affiche toujours event-v1. Conservez aussi ses pages, ses styles et son illustration ; modifier seulement une étiquette de version ne préserve pas un site.

Passez dans Topology. Homepage reachable signifie uniquement que l'accueil répond. Ce n'est pas un verdict d'acceptation de toute la version. Vous avez vérifié les parcours indépendamment et conservé une version complète de restauration.

Résumé

Vous avez installé une version séparée, l'avez sélectionnée sans écraser les anciens fichiers, puis avez validé des pages et liens réels. Vous avez aussi conservé une version complète dont le bon fonctionnement est connu. Dans le prochain TP, vous utiliserez cette possibilité de restauration lorsqu'une version possède un accueil fonctionnel mais un parcours important défaillant.