Basé sur le dépôt discourse_docker, j’ai écrit un petit script pour automatiser son utilisation dans une machine Vagrant (exécutez avec set -x pour voir ce qui est réellement fait)
Est-ce que j’ai copié la sauvegarde au mauvais endroit ?
Et que signifie la ligne de journal Vérification que /var/www/discourse/tmp/restores/default/2020-05-13-190832 existe... ?
~/infra/discourse sur master! ⌚ 21:14:07
$ pwd
/home/pihentagy/infra/discourse
~/infra/discourse sur master! ⌚ 21:01:14
$ ./wl.sh start
+ set -e
+ VAGRANT_MACHINE_NAME=guest
+ cd discourse
+ case "$1" in
+ init
+ printf 'Vérification et mise à jour du dépôt…\n'
Vérification et mise à jour du dépôt…
+ cd ..
+ git clone https://github.com/discourse/discourse_docker.git discourse
fatal: le chemin de destination 'discourse' existe déjà et n'est pas un répertoire vide.
+ printf 'Dépôt déjà présent\n'
Dépôt déjà présent
+ cd discourse
+ printf 'Mise à jour du dépôt…\n'
Mise à jour du dépôt…
+ git pull -r
remote: Énumération des objets : 6, terminé.
remote: Comptage des objets : 100% (6/6), terminé.
remote: Compression des objets : 100% (4/4), terminé.
remote: Total 6 (delta 2), réutilisé 5 (delta 2), pack non réutilisé 0
Décompression des objets : 100% (6/6), terminé.
De https://github.com/discourse/discourse_docker
3e465a2..49ed141 master -> origin/master
Autostash créé : 36aae80
HEAD est maintenant sur 3e465a2 Supprimer toutes les traces pg12 pour éviter la confusion de pg_wrapper
Tout d'abord, retour à la tête pour rejouer votre travail par-dessus...
Avancement rapide de master vers 49ed14152971f7f4a7437657987952be44c33c0a.
L'application de l'autostash a entraîné des conflits.
Vos modifications sont sécurisées dans le stash.
Vous pouvez exécuter "git stash pop" ou "git stash drop" à tout moment.
+ printf 'Copie du fichier de configuration…\n'
Copie du fichier de configuration…
+ cp ../resources/discourse.yml containers/
+ echo 'Démarrage de la machine Vagrant...'
Démarrage de la machine Vagrant...
+ vagrant up
Mise en service de la machine 'dockerhost' avec le fournisseur 'virtualbox'...
===> dockerhost: Vérification si la boîte 'ubuntu/xenial64' est à jour...
===> dockerhost: La machine est déjà approvisionnée. Exécutez `vagrant provision` ou utilisez le flag `--provision`
===> dockerhost: pour forcer l'approvisionnement. Les provisionneurs marqués pour toujours s'exécuter continueront de le faire.
+ vagrant ssh -c 'cd /vagrant;sudo ./launcher start discourse'
2627afdfbaac
Rien à faire, votre conteneur a déjà démarré !
Connexion à 127.0.0.1 fermée.
+ exit 0
~/infra/discourse sur master! ⌚ 21:07:56
$ ./wl.sh restore /home/pihentagy/infra/icontest-2020-05-12-033823-v20200506044956.tar.gz
+ set -e
+ VAGRANT_MACHINE_NAME=guest
+ cd discourse
+ case "$1" in
+ shift
+ backup=/home/pihentagy/infra/icontest-2020-05-12-033823-v20200506044956.tar.gz
+ discourse_backup_dir=shared/standalone/backups/default
+ mkdir --parents shared/standalone/backups/default
+ rsync -P --verbose /home/pihentagy/infra/icontest-2020-05-12-033823-v20200506044956.tar.gz shared/standalone/backups/default
icontest-2020-05-12-033823-v20200506044956.tar.gz
390,774,609 100% 317.41Mo/s 0:00:01 (xfr#1, to-chk=0/1)
envoyé 390,870,133 octets reçu 35 octets 156,348,067.20 octets/seconde
total de la taille 390,774,609 accélération de 1.00
+ vagrant ssh -c 'sudo docker exec -w /var/www/discourse -i discourse discourse enable_restore'
La restauration est désormais autorisée. Désactivez-la avec `disable_restore`
Connexion à 127.0.0.1 fermée.
+ vagrant ssh -c 'sudo docker exec -w /var/www/discourse -i discourse discourse restore'
Vous devez fournir un nom de fichier à restaurer. Voulez-vous dire l'un des suivants ?
Connexion à 127.0.0.1 fermée.
+ vagrant ssh -c 'sudo docker exec -w /var/www/discourse -i discourse discourse restore icontest-2020-05-12-033823-v20200506044956.tar.gz'
Démarrage de la restauration : icontest-2020-05-12-033823-v20200506044956.tar.gz
[DÉBUTÉ]
'system' a lancé la restauration !
Marquage de la restauration comme en cours...
Vérification que /var/www/discourse/tmp/restores/default/2020-05-13-190832 existe...
Copie de l'archive vers le répertoire temporaire...
EXCEPTION : lib/discourse.rb:90:in `exec': Échec de la copie de l'archive vers le répertoire temporaire.
cp: impossible de stat '/var/www/discourse/public/backups/default/icontest-2020-05-12-033823-v20200506044956.tar.gz' : Aucun fichier ou répertoire de ce type
lib/discourse.rb:100:in `execute_command'
lib/discourse.rb:90:in `exec'
lib/discourse.rb:40:in `execute_command'
/var/www/discourse/lib/backup_restore/local_backup_store.rb:42:in `download_file'
/var/www/discourse/lib/backup_restore/backup_file_handler.rb:61:in `copy_archive_to_tmp_directory'
/var/www/discourse/lib/backup_restore/backup_file_handler.rb:21:in `decompress'
/var/www/discourse/lib/backup_restore/restorer.rb:42:in `run'
script/discourse:143:in `restore'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/thor-1.0.1/lib/thor/command.rb:27:in `run'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/thor-1.0.1/lib/thor/invocation.rb:127:in `invoke_command'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/thor-1.0.1/lib/thor.rb:392:in `dispatch'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/thor-1.0.1/lib/thor/base.rb:485:in `start'
script/discourse:284:in `<top (required)>'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.4/lib/bundler/cli/exec.rb:63:in `load'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.4/lib/bundler/cli/exec.rb:63:in `kernel_load'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.4/lib/bundler/cli/exec.rb:28:in `run'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.4/lib/bundler/cli.rb:476:in `exec'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.4/lib/bundler/vendor/thor/lib/thor/command.rb:27:in `run'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.4/lib/bundler/vendor/thor/lib/thor/invocation.rb:127:in `invoke_command'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.4/lib/bundler/vendor/thor/lib/thor.rb:399:in `dispatch'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.4/lib/bundler/cli.rb:30:in `dispatch'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.4/lib/bundler/vendor/thor/lib/thor/base.rb:476:in `start'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.4/lib/bundler/cli.rb:24:in `start'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.4/exe/bundle:46:in `block in <top (required)>'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.4/lib/bundler/friendly_errors.rb:123:in `with_friendly_errors'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.4/exe/bundle:34:in `<top (required)>'
/usr/local/bin/bundle:23:in `load'
/usr/local/bin/bundle:23:in `<main>'
Tentative de retour en arrière...
Aucun besoin de retour en arrière
Nettoyage...
Suppression du répertoire temporaire '/var/www/discourse/tmp/restores/default/2020-05-13-190832'...
Reprise de sidekiq...
Marquage de la restauration comme terminée...
Notification à 'system' de la fin de la restauration...
Terminé !
[ÉCHOUÉ]
Restauration terminée.
Connexion à 127.0.0.1 fermée.
vagrant n’est pas pris en charge, mais voici tout de même quelques conseils.
Je ne suis pas sûr de savoir comment fonctionne rsync. Le chemin doit-il se terminer par une barre oblique ? Si le fichier se retrouve dans le bon répertoire, assurez-vous que le fichier copié est lisible par le serveur.
Donc, est-ce que vagrant (virtualbox) peut causer certains problèmes ?
~/infra/discourse on master! ⌚ 23:22:23
$ tree discourse/shared
discourse/shared
└── standalone
└── backups
└── default
└── icontest-2020-05-12-033823-v20200506044956.tar.gz
3 répertoires, 1 fichier
~/infra/discourse on master! ⌚ 23:22:27
$ ls discourse/shared/standalone/backups/default
icontest-2020-05-12-033823-v20200506044956.tar.gz
~/infra/discourse on master! ⌚ 23:22:36
$ ls -l discourse/shared/standalone/backups/default
total 381620
-rw-r--r-- 1 pihentagy pihentagy 390774609 May 13 21:08 icontest-2020-05-12-033823-v20200506044956.tar.gz
Il semble que le fichier soit lisible par tous et qu’il se trouve au bon endroit. Depuis l’intérieur du conteneur Docker discourse, où devrais-je voir la sauvegarde ? Mon script de restauration automatique est-il correct ou dois-je copier le fichier à l’intérieur du conteneur Docker ? Si oui, où ? (Peut-être y a-t-il des guides sur la façon d’automatiser Discourse depuis l’extérieur [de Docker] ?)
+ vagrant ssh -c 'sudo docker exec -w /var/www/discourse -i discourse discourse restore'
Vous devez fournir un nom de fichier à restaurer. Voulez-vous dire l'un des suivants ?
Connection to 127.0.0.1 closed.
+ vagrant ssh -c 'sudo docker exec -w /var/www/discourse -i discourse discourse restore icontest-2020-05-12-033823-v20200506044956.tar.gz'
Démarrage de la restauration : icontest-2020-05-12-033823-v20200506044956.tar.gz
[
Ce n’est pas obligatoire, mais ne pas terminer le chemin par une barre oblique est une mauvaise pratique, car le résultat dépend du fait que le répertoire existe déjà ou non.
Si le répertoire de destination existe déjà, une barre oblique n’est pas nécessaire et le fichier est copié à l’intérieur de ce répertoire.
Si le répertoire de destination n’existe pas et qu’il n’y a pas de barre oblique à la fin, le fichier est copié sous le nom ‘default’.
Si le répertoire de destination n’existe pas et qu’il y a une barre oblique à la fin, le répertoire est créé et le fichier est copié à l’intérieur.
Dans ce cas, la copie semble réussir (par chance).
Cependant,
Puisqu’aucune suggestion n’apparaît après « Voulez-vous dire l’un des éléments suivants ? », le fichier n’est pas au bon endroit. Il semble que les lecteurs soient mappés incorrectement dans le conteneur Docker.
Vous pouvez lancer une sauvegarde depuis l’intérieur de Docker (discourse backup) et vérifier où elle se trouve sur votre système de fichiers hôte.
Étrangement, elle n’est pas visible depuis le système de fichiers hôte. Est-ce normal ?
vagrant@ubuntu-xenial:~$ sudo docker exec -w /var/www/discourse -i discourse discourse backup
Démarrage de la sauvegarde...
[COMMENCÉ]
'system' a lancé la sauvegarde !
Marquage de la sauvegarde comme en cours...
Vérification de l'existence de '/var/www/discourse/tmp/backups/default/2020-05-14-121930'...
Vérification de l'existence de '/var/www/discourse/public/backups/default'...
Mise à jour des métadonnées...
Mise en pause de sidekiq...
Attente de la fin des tâches en cours par sidekiq...
Vidage du schéma public de la base de données...
…
Beaucoup de choses liées à pg_dump
…
Reprise de sidekiq...
Finalisation de la sauvegarde...
Création de l'archive : discourse-2020-05-14-121930-v20200512064023.tar.gz
Vérification que l'archive n'existe pas déjà...
Création d'une archive vide...
Archivage du vidage des données...
Archivage des fichiers uploadés...
Suppression du répertoire temporaire '/var/www/discourse/tmp/backups/default/2020-05-14-121930'...
Compression gzip de l'archive, cela peut prendre un certain temps...
Exécution du crochet after_create_hook pour la sauvegarde...
Suppression des anciennes sauvegardes...
Nettoyage...
Suppression des restes '.tar'...
Marquage de la sauvegarde comme terminée...
Actualisation des statistiques du disque...
Terminé !
[SUCCÈS]
Sauvegarde effectuée.
Le fichier de sortie se trouve dans : /var/www/discourse/public/backups/default/discourse-2020-05-14-121930-v20200512064023.tar.gz
vagrant@ubuntu-xenial:~$ find / -name discourse-2020-05-14-121930-v20200512064023.tar.gz 2>/dev/null
vagrant@ubuntu-xenial:~$ sudo docer exec -w /var/www/discourse -i discourse discourse enable_restore
sudo: docer: commande introuvable
vagrant@ubuntu-xenial:~$ sudo docker exec -w /var/www/discourse -i discourse discourse enable_restore
La restauration est maintenant autorisée. Désactivez-la avec `disable_restore`
vagrant@ubuntu-xenial:~$ sudo docker exec -w /var/www/discourse -i discourse discourse restore
Vous devez fournir un nom de fichier à restaurer. Voulez-vous dire l'un des suivants ?
discourse restore discourse-2020-05-14-121930-v20200512064023.tar.gz
discourse restore discourse-2020-05-14-121710-v20200512064023.tar.gz
discourse restore discourse-2020-05-14-120436-v20200512064023.tar.gz
Hors sujet : y a-t-il un moyen de surligner des lignes dans les blocs de code ?
En général, /var/discourse/shared/standalone/backups est le répertoire qui est visible dans votre conteneur sous le chemin /var/www/discourse/public/backups (d’où le mot shared). Votre commande rsync place la sauvegarde dans ce répertoire afin de la rendre accessible depuis l’intérieur du conteneur.
À l’inverse, si le conteneur écrit dans public/backups, cela devrait être visible sur votre hôte dans le répertoire partagé.
J’ai écrit /var/discourse/shared.... ci-dessus. Mais il semble que vous travailliez dans ~/infra/discourse, donc vous copiez vers ~/infra/discourse/shared/standalone/backups/default.
Habituellement, le conteneur est mappé sur /var/discourse/shared/....
Cela pourrait être le problème. Pouvez-vous vérifier si vous avez un répertoire /var/discourse/shared ?
Cependant, si j’entre dans la machine Docker, il est là
root@ubuntu-xenial-discourse:/var/www/discourse/public/backups/default# ls
discourse-2020-05-14-120436-v20200512064023.tar.gz discourse-2020-05-14-121930-v20200512064023.tar.gz
discourse-2020-05-14-121710-v20200512064023.tar.gz discourse-2020-05-14-125606-v20200512064023.tar.gz
Ma question est donc : si je crée une sauvegarde, devrais-je la voir depuis l’extérieur de Docker ?
En attendant, j’ai simplement créé une machine vagrant et fait un git clone depuis l’intérieur dans le répertoire standard /var/discourse. La seule “bizarrerie” est que j’ai un fichier discourse.yml à l’intérieur du conteneur, et non app.yml.
Oui, et c’est la même chose que votre problème initial :
« si vous avez une sauvegarde en dehors de Docker et que vous la placez dans le répertoire partagé, vous devriez la voir à l’intérieur de Docker » (et vous ne la voyez pas).
Le problème vient de vos répertoires partagés et cela est dû à ceci :
Je voulais dire : pour l’instant, j’ai recréé une nouvelle machine Vagrant, sans copier de sauvegardes précédentes. J’ai effectué le bootstrap et lancé le conteneur Docker. J’ai ensuite réalisé la sauvegarde.
Rien n’est visible dans la machine Vagrant en dehors du conteneur Docker.
Je pense avoir trouvé le problème : j’ai monté ce dossier partagé Docker dans la machine Vagrant parente.
Si je commente cette ligne dans mon fichier Vagrantfile, les sauvegardes réapparaissent “magiquement”.
Le problème venait donc du fait que le dossier partagé Vagrant (vers le haut) et le dossier partagé Docker (vers le bas) entraient en conflit, rendant le montage invalide.
