Déposer la sauvegarde de Cornucopia sur les deux travailleurs, au même chemin, puis faire les deux ajustements déjà vus au laboratoire Compose : la base de données vers le service db, et le repointage de l'adresse dans l'export.
Pour mieux comprendre
On ne repart pas d'un site vide : la sauvegarde complète de la ferme (fichiers et base de données) reprend vie sur le cluster, comme aux laboratoires Docker et Compose. L'image wordpress:7.1 repart à neuf, mais le site et sa base de données sont ceux de Flora : rien ne disparaît.
Le problème que cette étape résout. Au laboratoire Compose, tout se passait sur une seule machine : le zip déballé à côté de la partition, et les répertoires partagés qui pointent dessus. Dans l'essaim, la pile est déployée depuis swarm-node01, mais les conteneurs WordPress tourneront sur swarm-node04 et 05, et la base sur swarm-node04. Or l'essaim ne copie jamais un fichier d'un noeud à l'autre. Un répertoire partagé dans une pile veut dire « ce chemin, sur le noeud où la tâche atterrit ». Si les fichiers n'y sont pas, WordPress démarre sur un répertoire vide et l'image installe un site vierge. D'où cette étape à part, avant la pile : on prépare le terrain sur les travailleurs, puis on décrit et on déploie depuis le gestionnaire.
Les trois gestes, et sur quels noeuds
- Déballer le zip sur les deux travailleurs, swarm-node04 et swarm-node05, au même chemin
/home/docker/swarm/sauvegarde.
- Changer une ligne de wp-config.php, sur les deux travailleurs aussi :
DB_HOST devient db:3306.
- Le repointage de l'adresse, Ã la fin de l'export, sur swarm-node04 seulement.
Démarche - la sauvegarde sur chaque travailleur
swarm-node04 ET swarm-node05 - déballer la sauvegarde
$ sudo mkdir -p /home/docker/swarm
$ cd /home/docker/swarm
$ sudo wget https://evolutif.projet.autos/laboratoire/conteneurs/swarm/guide/sauvegarde-cornucopia-formation.zip
$ sudo unzip sauvegarde-cornucopia-formation.zip -d sauvegarde
$ ls sauvegarde
base-de-donnees.sql fichiers-wordpress README.md
$ sudo chown -R www-data:www-data sauvegarde/fichiers-wordpress
$ sudo nano sauvegarde/fichiers-wordpress/wp-config.php
Les deux travailleurs, parce que la contrainte de placement de la pile dira « n'importe quel travailleur » : une réplique WordPress peut atterrir sur l'un ou sur l'autre, et chacun doit trouver le site au même chemin. Le chown vers www-data permet à Apache, dans le conteneur, d'écrire ses téléversements et ses mises à jour.
Pourquoi DB_HOST change. La sauvegarde vient du serveur en ligne, où la base de données vivait sur localhost, à côté du site. Ici, la base est un service de la pile nommé db, qui tourne sur un autre noeud que certaines répliques WordPress. C'est le DNS interne de l'essaim qui traduit ce nom, même d'un noeud à l'autre, grâce au réseau overlay net créé à l'étape 03. Aucun numéro IP dans la configuration.
Démarche - le repointage de l'adresse
La sauvegarde croit que le site vit à https://cornucopia.projet.autos. On ajoute à la fin de l'export les trois requêtes de repointage vues au laboratoire Docker : elles s'exécuteront toutes seules lors de l'import initial de la base, au premier démarrage du service db.
swarm-node04 seulement - le repointage à la fin de l'export
$ sudo tee -a sauvegarde/base-de-donnees.sql <<'FIN'
UPDATE wp_options SET option_value='http://192.168.56.10'
WHERE option_name IN ('siteurl','home');
UPDATE wp_posts SET post_content = REPLACE(post_content,
'https://cornucopia.projet.autos', 'http://192.168.56.10');
UPDATE wp_posts SET guid = REPLACE(guid,
'https://cornucopia.projet.autos', 'http://192.168.56.10');
FIN
Pourquoi swarm-node04 seulement. La base y sera ancrée par la contrainte node.hostname == swarm-node04 de la pile, et c'est l'export de ce noeud qui sera monté dans /docker-entrypoint-initdb.d/. Le zip est aussi déballé sur swarm-node05, mais son export ne servira jamais : seul celui de swarm-node04 doit porter le repointage.
Pourquoi 192.168.56.10. Par le maillage de routage, n'importe quel noeud de l'essaim répond sur le port 80, mais WordPress n'a qu'une adresse dans sa base. On prend celle du chef, qui est aussi celle du tableau de bord Traefik et du visualiseur. Avec un autre plan d'adressage, adaptez cette valeur : c'est la seule qui varie.
L'image mysql n'importe le fichier de /docker-entrypoint-initdb.d/ qu'au premier démarrage, quand /home/docker/swarm/database est vide sur swarm-node04. Si vous déployez la pile avant d'avoir ajouté le repointage, la base est créée avec l'ancienne adresse et le navigateur vous renvoie vers le vrai site, cornucopia.projet.autos. Corriger l'export après coup ne sert à rien : docker stack rm wordpress-sticky depuis un gestionnaire, sudo rm -rf /home/docker/swarm/database sur swarm-node04, corrigez l'export, puis redéployez. C'est le mécanisme de l'incendie volontaire du laboratoire Compose, vu de l'autre côté : là -bas on s'en sert pour renaître, ici il faut l'avoir compris pour ne pas se faire piéger. Question d'examen classique.
Avant de lancer quoi que ce soit : sur les deux travailleurs, ls /home/docker/swarm/sauvegarde montre les trois éléments et grep DB_HOST sauvegarde/fichiers-wordpress/wp-config.php répond db:3306; sur swarm-node04, tail -n 6 sauvegarde/base-de-donnees.sql montre les requêtes de repointage. Rien n'est encore déployé, tout se corrige encore d'un simple nano.
