Introduction
Willow Commons déplace son site vers une nouvelle adresse de serveur. La communauté doit continuer à utiliser site.community.test et l'emplacement original doit rester disponible pendant la transition. Les deux backends contiennent déjà leurs programmes légitimes ; votre travail concerne la migration DNS, pas la publication de contenu.
Terminez d'abord Voir l'adresse utilisée par un client. Cet environnement indépendant recommence avec le nom officiel sur l'ancienne adresse, un serveur faisant autorité et des résolveurs de cache séparés, ainsi que les deux services HTTP prêts. Il ne réutilise pas votre VM précédente. Vous préparerez le TTL, changerez l'adresse et vérifierez les clients réels et le contenu complet. Prévoyez environ 50 minutes, lecture et erreurs courantes comprises ; il s'agit d'une estimation de l'auteur.
Cet exercice DNS local est contrôlé. Il ne promet ni propagation mondiale, ni absence d'interruption, ni migration d'un registraire public, ni autorisation de supprimer immédiatement l'ancien serveur.
Préparer la fenêtre de transition
Dans cette étape, vous vérifierez le service normal et le nouveau backend avant de raccourcir le TTL de l'enregistrement officiel. Commencez dans Community Preview, sélectionnez Warm Client et consultez la page Willow Commons existante avec son étiquette old location. N'utilisez pas Fresh Client avant le changement d'adresse. Son résolveur séparé n'a pas encore interrogé ce site.
Passez dans Warm Client. Les commandes et options curl sont les mêmes que dans la première unité. Demandez d'abord le service existant par son nom :
curl --noproxy '*' -fsS --max-time 5 http://site.community.test:8081/programme.txt
Vous devez obtenir le programme complet de Service location: old. Vérifiez ensuite le nouveau backend préparé par son adresse, avec le même chemin et le même port :
curl --noproxy '*' -fsS --max-time 5 http://10.94.0.20:8081/programme.txt
Vous devez retrouver les trois rencontres et les informations d'entrée, avec Service location: new. Ce test direct de disponibilité contourne DNS volontairement ; il ne prouve pas qu'un client utilisant le nom a migré. Gardez les deux sites inchangés.
Interrogez la copie actuelle de Warm Client :
dig @127.0.0.1 site.community.test A +noall +answer
Vous devez obtenir l'ancienne adresse avec un TTL ne dépassant pas 120. Si la copie initialement mise en cache a expiré pendant votre lecture, cette véritable requête obtient une autre copie de l'ancien enregistrement toujours en vigueur. Aucun délai ne commence à l'ouverture du laboratoire.
Passez dans DNS Desk, dans /home/labex/project/site-move, et lisez le fichier de zone et le plan des backends préparés :
cat backends.tsv
cat community.zone
Les modifications de migration se limitent à l'adresse A et au TTL de site, ainsi qu'au serial SOA nécessaire. practice est réservé aux observations répétables facultatives ; conservez keep, le serveur de noms et tous les octets des sites. L'ancien enregistrement préparé possède un véritable TTL de 120 secondes. L'exercice utilise volontairement des secondes ; il ne prétend pas qu'une durée de cache d'un jour en production disparaît en deux minutes.
Avant de changer l'adresse, réduisez uniquement le TTL de l'enregistrement officiel. Ce here-document littéral complet utilise la syntaxe d'écriture de fichier enseignée dans la première unité :
cat > community.zone <<'ZONE'
$TTL 120
@ IN SOA ns.community.test. admin.community.test. (2 60 30 3600 30)
@ IN NS ns.community.test.
ns IN A 10.94.0.2
site 45 IN A 10.94.0.10
practice 120 IN A 10.94.0.10
keep 120 IN A 10.94.0.10
ZONE
named-checkzone community.test community.zone
Vous devez voir loaded serial 2 et OK ; corrigez tout problème de syntaxe avant de recharger :
sudo /opt/labex/site-move/reload-zone
Confirmez les données du serveur faisant autorité en fonctionnement, pas seulement le fichier sauvegardé :
sudo ip netns exec site-authority dig @10.94.0.2 site.community.test A +noall +answer
Vous devez obtenir 45 IN A 10.94.0.10. L'ancien backend reste la réponse faisant autorité. Passez dans Warm Client :
dig @127.0.0.1 site.community.test A +noall +answer
L'ancienne copie en cache conserve sa durée restante précédente. Ne prenez pas un TTL restant de 40 pour la preuve que la nouvelle politique de 45 secondes a été obtenue : une ancienne copie de 120 secondes peut elle aussi n'avoir plus que 40 secondes.
Attendez l'expiration de la copie ancienne observée, puis interrogez de nouveau. Vous pouvez attendre les dernières secondes restantes affichées, plus une. La commande prudente complète ci-dessous couvre le maximum original de 120 secondes :
sleep 121
dig @127.0.0.1 site.community.test A +noall +answer
Vous devez obtenir l'ancienne adresse avec un TTL nouvellement acquis d'environ 45 secondes. Cette dernière requête DNS est importante : l'expiration retire une copie ancienne, mais ne récupère pas sa remplaçante. L'échange DNS natif enregistre la réponse de l'ancienne adresse avec sa durée réduite. La vérification lit cet échange existant avant toute sonde et ne prépare jamais cette étape à votre place.
Si la réponse est absente ou indique une autre adresse, relisez les sorties exactes du serveur faisant autorité et du client avant de continuer. Corrigez le fichier dans DNS Desk, validez, rechargez et réessayez la recherche par nom dans Warm Client. Ne redémarrez ni ne videz un résolveur. Ne lancez la vérification de cette étape qu'après avoir réellement obtenu l'ancienne adresse avec sa durée réduite.
Changer l'adresse et comparer deux clients
Dans cette étape, vous déplacerez le nom officiel et comparerez des clients indépendants. Lisez l'étape avant de commencer la courte séquence. La prochaine recherche warm montre la fenêtre de comparaison restante ; un accès au cache ne redémarre pas son TTL. Seule une nouvelle copie obtenue après expiration naturelle commence une nouvelle durée de 45 secondes, indépendamment de la préparation de l'environnement. Une modification lente peut manquer la différence visible ; la migration reste valide et la récupération par nom d'entraînement séparé permet de répéter l'observation.
Dans Warm Client, actualisez votre observation :
dig @127.0.0.1 site.community.test A +noall +answer
Si le TTL restant est presque épuisé, laissez-le expirer et relancez la recherche avant la modification, tant que le serveur faisant autorité retourne encore l'ancienne adresse. Passez ensuite dans DNS Desk. Changez l'adresse A officielle, conservez son TTL de 45 secondes et augmentez le serial :
cat > community.zone <<'ZONE'
$TTL 120
@ IN SOA ns.community.test. admin.community.test. (3 60 30 3600 30)
@ IN NS ns.community.test.
ns IN A 10.94.0.2
site 45 IN A 10.94.0.20
practice 120 IN A 10.94.0.10
keep 120 IN A 10.94.0.10
ZONE
named-checkzone community.test community.zone
sudo /opt/labex/site-move/reload-zone
sudo ip netns exec site-authority dig @10.94.0.2 site.community.test A +noall +answer
Le serveur faisant autorité en fonctionnement doit maintenant retourner 45 IN A 10.94.0.20. S'il retourne encore l'ancienne adresse, le fichier sauvegardé et les données chargées diffèrent : vérifiez la syntaxe et le résultat du rechargement avant d'interpréter le cache d'un client.
Passez dans Warm Client :
dig @127.0.0.1 site.community.test A +noall +answer
curl --noproxy '*' -fsS --max-time 5 http://site.community.test:8081/programme.txt
Pendant la durée restante de sa copie, il peut légitimement utiliser l'ancienne adresse et retourner Service location: old. Passez dans Fresh Client, qui démarre dans /home/labex/project/site-move/fresh avec son propre résolveur :
dig @127.0.0.1 site.community.test A +noall +answer
curl --noproxy '*' -fsS --max-time 5 http://site.community.test:8081/programme.txt
Vous devez obtenir la nouvelle adresse et le programme complet de Service location: new. Deux clients peuvent utiliser le même nom tout en atteignant des backends valides différents pendant une transition DNS. Ce sont des espaces de noms client Linux et des processus de cache indépendants dans une seule VM, pas deux appareils physiques ni deux VM indépendantes.
Si les deux affichent déjà new : la copie warm a expiré naturellement avant la comparaison. Poursuivez la migration officielle ; aucune capture ni aucun chevauchement historique ne sont exigés pour réussir. Pour répéter le phénomène sans l'annuler, utilisez practice.community.test comme dans la première unité. Dans DNS Desk, conservez site à sa nouvelle adresse, remettez uniquement practice à l'ancienne adresse et 120 secondes, puis augmentez le serial actuel avec nano community.zone (Ctrl+O, Enter, Ctrl+X). Validez et rechargez. Dans Warm Client, laissez expirer toute copie d'entraînement actuelle, puis interrogez practice pour ouvrir une nouvelle fenêtre. Changez uniquement practice vers la nouvelle adresse et 45 secondes avec un autre serial supérieur, validez et rechargez, puis comparez practice via les deux clients. L'enregistrement officiel site reste migré tout au long du processus. Terminez l'observation d'entraînement naturellement ; ne videz jamais un cache et ne remplacez pas le contenu des sites.
Si vous avez changé l'adresse officielle avant de terminer la préparation du TTL, utilisez la procédure d'édition apprise pour remettre uniquement site à l'ancienne adresse et 45 secondes avec un serial supérieur. Validez, rechargez et laissez expirer la réponse actuelle de Warm Client. Demandez l'ancienne adresse avec le TTL court, puis effectuez de nouveau la bascule avec un serial encore supérieur. Les deux backends originaux restant disponibles, ce retour arrière DNS limité corrige l'ordre sans réinitialiser les services ni supprimer le travail. L'objectif final reste la nouvelle adresse officielle. Lancez la vérification de cette étape après avoir confirmé le changement du serveur faisant autorité en fonctionnement.
Confirmer le nouveau parcours par DNS
Dans cette étape, vous prouverez que les clients contrôlés atteignent le nouveau contenu et que l'ancien service reste disponible. Commencez dans Warm Client. Sa copie initiale de migration dure au plus 60 secondes selon la politique autorisée ; le parcours montré utilise 45. Inspectez le TTL restant :
dig @127.0.0.1 site.community.test A +noall +answer
S'il indique encore l'ancienne adresse, attendez les secondes restantes plus une, puis recommencez. Cette attente prudente complète couvre la durée courte maximale autorisée :
sleep 61
dig @127.0.0.1 site.community.test A +noall +answer
Vous devez obtenir 10.94.0.20, avec un TTL restant ne dépassant pas 45 pour la politique montrée. Une adresse correcte ne suffit pas : demandez la page d'accueil et sauvegardez le programme complet par ce nom :
curl --noproxy '*' -fsS --max-time 5 http://site.community.test:8081/
curl --noproxy '*' -fsS --max-time 5 -o programme.txt http://site.community.test:8081/programme.txt
cat programme.txt
Vous devez obtenir la véritable page d'accueil new location et le programme Service location: new, avec les trois rencontres et les informations d'entrée. Si DNS est correct mais le contenu ne l'est pas, examinez le chemin et l'adresse du backend réel ; modifier l'ancien site pour le faire ressembler au nouveau est hors périmètre.
Passez dans Fresh Client et sauvegardez indépendamment la même ressource complète :
dig @127.0.0.1 site.community.test A +noall +answer
curl --noproxy '*' -fsS --max-time 5 -o programme.txt http://site.community.test:8081/programme.txt
cat programme.txt
Vous devez obtenir le même contenu du nouvel emplacement. Passez dans Community Preview, revenez à sa page de sélection avec Back du navigateur si nécessaire, sélectionnez chaque client et actualisez la véritable page. Les deux affichent maintenant new location. Utilisez Download the programme dans chaque vue et ouvrez le texte complet. Ces requêtes du navigateur utilisent le client du cours sélectionné, indépendamment du DNS de l'ordinateur du navigateur.
Lisez l'étiquette new location près du haut et le lien original du programme sous les trois rencontres. Chaque client doit afficher cette véritable page du nouveau backend.
Revenez dans Warm Client pour prouver les exigences de conservation. Demandez directement l'ancien backend :
curl --noproxy '*' -fsS --max-time 5 http://10.94.0.10:8081/programme.txt
Vous devez obtenir le programme original de l'ancien emplacement. Interrogez le nom sans rapport avec la migration sur le serveur faisant autorité :
dig @10.94.0.2 keep.community.test A +noall +answer
Vous devez obtenir la valeur inchangée 120 IN A 10.94.0.10. L'ancien service fait toujours partie du contrat de transition. Ne l'arrêtez pas parce que deux clients ont migré : ces observations ne démontrent pas que tous les clients du monde réel se sont mis à jour.
Si un fichier sauvegardé contient un emplacement antérieur, répétez la même commande de téléchargement dans le bon onglet client après le changement de sa véritable recherche DNS. Si le chemin est incorrect, retrouvez votre position avec pwd et cd /home/labex/project/site-move/warm, ou le répertoire fresh correspondant. Les vérifications finales lisent les preuves DNS et de rechargement existantes avant leurs propres requêtes. Répéter l'évaluation ne vide pas les caches et ne recharge pas le serveur faisant autorité ; les lectures normales peuvent compléter les journaux natifs.
Résumé
Vous avez vérifié le nouveau backend, réduit le TTL pendant que l'ancienne adresse restait la réponse faisant autorité et laissé un véritable client obtenir cette politique. Vous avez ensuite changé l'adresse, comparé des clients indépendants et vérifié le nouveau contenu complet après expiration naturelle. Le nom original, l'ancien backend et les enregistrements sans rapport avec la migration restent disponibles. Il s'agit d'observations de clients contrôlés, pas d'une garantie de propagation DNS mondiale.
