Déplacer un service vers un autre hôte

AnsibleBeginner
Pratiquer maintenant

Introduction

Riverlight Weekend possède un programme fonctionnel, et une source de remplacement préparée est maintenant approuvée. Déplacez uniquement la connexion du programme vers le nouveau membre ; conservez le lieu, l’expérience actuelle des visiteurs et l’ancienne source.

Terminez d’abord Relier les pages de l’événement, ou maîtrisez groupes d’inventaire, hostvars, modèles, assertions uri en lecture seule et handlers. Ce laboratoire indépendant fournit le playbook et le modèle déjà enseignés. Aucune installation de service ni migration des données sources n’est requise ; la durée est une estimation de l’auteur.

Déplacer le programme sans supprimer l’ancienne source

Dans cette étape, vous changerez un groupe d’inventaire pour utiliser un programme de remplacement préparé, tout en conservant la connexion du lieu et la source d’origine.

Cet environnement est indépendant. Event Site sert déjà un programme Riverlight fonctionnel, mais le remplacement approuvé contient d’autres sessions. Ouvrez Program : l’ancien programme affiche Morning sketchbook et Lunch by the river. Visit et Visitor guide fonctionnent aussi et doivent rester disponibles pendant le changement de membres.

Passez à Controller, qui démarre dans /home/labex/project. Le connect.yml protégé et le modèle du laboratoire précédent sont fournis ; cette VM ne dépend pas de ses fichiers. Si vous perdez le répertoire, utilisez cd /home/labex/project. Lisez la sélection approuvée et les membres actuels :

cat approved-services.txt
cat inventory.ini
ansible-inventory --graph

Le programme approuvé est désormais sur web2, édition 2026-revised. L’inventaire sélectionne toujours web1, qui fournit l’ancien programme. web2 sert aussi le lieu sur un autre port : un hôte peut appartenir aux deux groupes, car les groupes expriment des rôles de service, sans imposer une machine par rôle. Les deux conteneurs sources partagent le noyau de la VM d’apprentissage ; l’entrée s’exécute sur le contrôleur.

Examinez les données d’hôte et les deux identités sources. Comme auparavant, curl --config lit dans un fichier l’URL et les options de signalement d’erreurs préparées :

cat host_vars/web2.yml
cat requests/new-program.conf
curl --config requests/new-program.conf
curl --config requests/old-program.conf

Les deux sources fonctionnent, mais seule la nouvelle édition doit être reliée à l’entrée actuelle. Déplacer la connexion n’autorise pas à supprimer l’ancienne source ou ses fichiers.

Lisez l’automatisation réutilisable fournie :

cat connect.yml
cat templates/routes.json.j2

groups['program'][0] sélectionne le membre du programme, et hostvars donne son adresse et program_port. L’expression du lieu utilise indépendamment son groupe et venue_port. Les assertions HTTP précèdent le modèle. Un changement de route notifie l’utilitaire préparé, qui recharge le processus d’entrée existant.

Remplacez le petit inventaire ci-dessous. Comme dans le premier laboratoire, utilisez cat, la redirection et un here-document protégé par des apostrophes. Collez le délimiteur final EOF seul sur sa ligne ; s’il manque, utilisez Ctrl+C et recommencez le bloc complet. Ne changez ni les données d’hôtes ni les éditions approuvées :

cat > inventory.ini <<'EOF'
[gateway]
entry ansible_connection=local ansible_python_interpreter=/usr/bin/python3

[program]
web2

[venue]
web2
EOF
ansible-inventory --graph

Les deux groupes doivent contenir web2. L’entry local reste dans [gateway]. Corrigez un nom de groupe mal orthographié ou un membre supplémentaire dans ce fichier avant de continuer ; ne compensez pas avec des adresses fixes dans le modèle.

Vérifiez la syntaxe et prévisualisez les routes proposées :

ansible-playbook connect.yml --syntax-check
ansible-playbook connect.yml --check --diff

Les requêtes HTTP de lecture s’exécutent pendant cette prévisualisation et doivent identifier le programme et le lieu approuvés. Seule la route du programme doit différer. L’adresse et le port du lieu restent identiques. La prévisualisation ne recharge pas la passerelle. Appliquez le changement :

ansible-playbook connect.yml

Attendez le changement du modèle et RUNNING HANDLER [Reload entry]. Ouvrez Event Site, suivez Program et confirmez que Paper and ink, Acoustic afternoon et Shared supper remplacent l’ancien planning. Cliquez sur Download the schedule, puis suivez Visit et Visitor guide. Le lieu et les conseils d’arrivée doivent rester identiques.

L’entrée doit afficher le programme de remplacement. Regardez les trois sessions et l’édition 2026-revised sous le lien de téléchargement :

Programme de remplacement relié à l’entrée existante

Revenez dans Controller. Enregistrez le téléchargement actuel dans la VM ; -o nomme le fichier de sortie :

curl -fsS http://127.0.0.1:8081/program/schedule.csv -o schedule.csv
cat schedule.csv

Le CSV doit contenir les trois sessions actuelles, pas les deux anciennes. Confirmez que l’ancienne source répond encore directement :

curl --config requests/old-program.conf

Elle doit toujours s’identifier comme program, riverlight, 2026-original. Elle a quitté la configuration d’entrée sans être arrêtée. Cela préserve les données et une référence indépendante sans prétendre qu’elle reste sélectionnée.

Relancez enfin le playbook :

ansible-playbook connect.yml

Attendez changed=0, failed=0 et aucun handler. Si une source est temporairement indisponible, le contrôle doit arrêter le play avant le modèle ; un échec de connexion ne demande pas de supprimer l’ancien nœud. Corrigez le membre choisi ou la référence aux données, puis réessayez. La comparaison sha256sum du premier laboratoire permet de confirmer qu’un fichier d’entrée n’a pas changé.

Gérez uniquement les membres d’inventaire, connect.yml et templates/routes.json.j2 réutilisables, et les routes via ce playbook. Préservez les variables fournies, site et éditions approuvés, contenus sources, notes privées, tous les services et la passerelle. Les requêtes et modèles doivent rester réutilisables avec d’autres membres, adresses et ports. Utilisez /opt/labex/service-links/reload.py avec le répertoire d’entrée du projet. Employez les tâches directes uri, assert, template et un handler command limité au rechargement ; ne masquez pas les échecs et n’écrivez rien en mode de vérification.

Résumé

Vous avez changé les membres du service au lieu d’intégrer une nouvelle adresse fixe, prévisualisé la route puis appliqué le changement. Le vrai site et son CSV ont confirmé le nouveau programme. L’ancienne source est restée accessible indépendamment, et le lieu ainsi que le guide sont restés intacts.