Basado en el repositorio discourse_docker, he escrito un pequeño script para automatizar su uso dentro de una máquina Vagrant (ejecútalo con set -x para ver qué se hace exactamente)
¿Copié la copia de seguridad a la ubicación incorrecta?
¿Y qué significa la línea del registro Asegurando que /var/www/discourse/tmp/restores/default/2020-05-13-190832 existe...?
~/infra/discourse en master! ⌚ 21:14:07
$ pwd
/home/pihentagy/infra/discourse
~/infra/discourse en master! ⌚ 21:01:14
$ ./wl.sh start
+ set -e
+ VAGRANT_MACHINE_NAME=guest
+ cd discourse
+ case "$1" in
+ init
+ printf 'Checking out and updating repo…\n'
Verificando y actualizando el repositorio…
+ cd ..
+ git clone https://github.com/discourse/discourse_docker.git discourse
fatal: destination path 'discourse' already exists and is not an empty directory.
+ printf 'Repo already there\n'
El repositorio ya está aquí
+ cd discourse
+ printf 'Updating repo…\n'
Actualizando el repositorio…
+ git pull -r
remote: Enumerating objects: 6, done.
remote: Counting objects: 100% (6/6), done.
remote: Compressing objects: 100% (4/4), done.
remote: Total 6 (delta 2), reused 5 (delta 2), pack-reused 0
Unpacking objects: 100% (6/6), done.
From https://github.com/discourse/discourse_docker
3e465a2..49ed141 master -> origin/master
Created autostash: 36aae80
HEAD is now at 3e465a2 Remove all pg12 traces so pg_wrapper doesn't get confused
First, rewinding head to replay your work on top of it...
Fast-forwarded master to 49ed14152971f7f4a7437657987952be44c33c0a.
Applying autostash resulted in conflicts.
Your changes are safe in the stash.
You can run "git stash pop" or "git stash drop" at any time.
+ printf 'Copying config file…\n'
Copiando el archivo de configuración…
+ cp ../resources/discourse.yml containers/
+ echo 'Starting Vagrant machine...'
Iniciando la máquina Vagrant...
+ vagrant up
Bringing machine 'dockerhost' up with 'virtualbox' provider...
==> dockerhost: Checking if box 'ubuntu/xenial64' is up to date...
==> dockerhost: Machine already provisioned. Run `vagrant provision` or use the `--provision`
==> dockerhost: flag to force provisioning. Provisioners marked to run always will still run.
+ vagrant ssh -c 'cd /vagrant;sudo ./launcher start discourse'
2627afdfbaac
Nothing to do, your container has already started!
Connection to 127.0.0.1 closed.
+ exit 0
~/infra/discourse en 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.41MB/s 0:00:01 (xfr#1, to-chk=0/1)
sent 390,870,133 bytes received 35 bytes 156,348,067.20 bytes/sec
total size is 390,774,609 speedup is 1.00
+ vagrant ssh -c 'sudo docker exec -w /var/www/discourse -i discourse discourse enable_restore'
Restore are now permitted. Disable them with `disable_restore`
Connection to 127.0.0.1 closed.
+ vagrant ssh -c 'sudo docker exec -w /var/www/discourse -i discourse discourse restore'
You must provide a filename to restore. Did you mean one of the following?
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'
Starting restore: icontest-2020-05-12-033823-v20200506044956.tar.gz
[STARTED]
'system' has started the restore!
Marking restore as running...
Asegurando que /var/www/discourse/tmp/restores/default/2020-05-13-190832 existe...
Copying archive to tmp directory...
EXCEPTION: lib/discourse.rb:90:in `exec': Failed to copy archive to tmp directory.
cp: cannot stat '/var/www/discourse/public/backups/default/icontest-2020-05-12-033823-v20200506044956.tar.gz': No such file or directory
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>'
Trying to rollback...
There was no need to rollback
Cleaning stuff up...
Removing tmp '/var/www/discourse/tmp/restores/default/2020-05-13-190832' directory...
Unpausing sidekiq...
Marking restore as finished...
Notifying 'system' of the end of the restore...
Finished!
[FAILED]
Restore done.
Connection to 127.0.0.1 closed.
Vagrant no es compatible, pero aquí tienes algunos consejos de todos modos.
No estoy seguro de cómo funciona rsync. ¿Necesita que la ruta termine con una barra? Si el archivo termina en el directorio correcto, asegúrate de que el archivo copiado sea legible por el servidor.
Entonces, ¿puede vagrant (virtualbox) causar algunos problemas?
~/infra/discourse on master! ⌚ 23:22:23
$ tree discourse/shared
discourse/shared
└── standalone
└── backups
└── default
└── icontest-2020-05-12-033823-v20200506044956.tar.gz
3 directories, 1 file
~/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
Parece que el archivo es legible para todos y está en el lugar correcto. Desde dentro del contenedor Docker discourse, ¿dónde debería ver la copia de seguridad? ¿Está correcto mi script de restauración automática o debería copiarlo dentro del contenedor Docker? Si es así, ¿dónde? (¿Quizás haya alguna guía sobre cómo automatizar Discourse desde fuera [de Docker]?)
+ vagrant ssh -c 'sudo docker exec -w /var/www/discourse -i discourse discourse restore'
You must provide a filename to restore. Did you mean one of the following?
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'
Starting restore: icontest-2020-05-12-033823-v20200506044956.tar.gz
[
No es obligatorio, pero no terminar la ruta con una barra es una mala práctica, ya que el resultado depende de si el directorio ya existe o no.
Si el directorio de destino ya existe, no es necesario poner una barra y el archivo se copia dentro del directorio.
Si el directorio de destino no existe y no hay una barra al final, el archivo se copia con el nombre ‘default’.
Si el directorio de destino no existe y hay una barra al final, se crea el directorio y el archivo se copia dentro de él.
En este caso, la copia parece haber funcionado bien (por suerte).
Sin embargo,
Dado que no hay sugerencias después de “Did you mean one of the following?”, el archivo no está en el lugar correcto. Parece que las unidades están mapeadas incorrectamente en el contenedor de Docker.
Podrías iniciar una copia de seguridad desde dentro de Docker (discourse backup) y ver dónde termina en tu sistema de archivos del host.
Curiosamente, no es visible desde el sistema de archivos del host. ¿Debería serlo?
vagrant@ubuntu-xenial:~$ sudo docker exec -w /var/www/discourse -i discourse discourse backup
Iniciando copia de seguridad...
[INICIADO]
¡'system' ha iniciado la copia de seguridad!
Marcando copia de seguridad como en ejecución...
Asegurando que '/var/www/discourse/tmp/backups/default/2020-05-14-121930' exista...
Asegurando que '/var/www/discourse/public/backups/default' exista...
Actualizando metadatos...
Pausando sidekiq...
Esperando a que sidekiq termine de ejecutar trabajos...
Volcando el esquema público de la base de datos...
…
Muchísimo de pg_dump stuff"
…
Reanudando sidekiq...
Finalizando copia de seguridad...
Creando archivo comprimido: discourse-2020-05-14-121930-v20200512064023.tar.gz
Asegurando que el archivo comprimido no exista ya...
Creando archivo comprimido vacío...
Archivando volcado de datos...
Archivando subidas...
Eliminando directorio temporal '/var/www/discourse/tmp/backups/default/2020-05-14-121930'...
Comprimiendo archivo con gzip, esto puede tardar un rato...
Ejecutando el after_create_hook para la copia de seguridad...
Eliminando copias de seguridad antiguas...
Limpiando cosas...
Eliminando restos de '.tar'...
Marcando copia de seguridad como finalizada...
Refrescando estadísticas del disco...
¡Finalizado!
[ÉXITO]
Copia de seguridad realizada.
El archivo de salida está en: /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: comando no encontrado
vagrant@ubuntu-xenial:~$ sudo docker exec -w /var/www/discourse -i discourse discourse enable_restore
Las restauraciones ahora están permitidas. Deshabilítalas con `disable_restore`
vagrant@ubuntu-xenial:~$ sudo docker exec -w /var/www/discourse -i discourse discourse restore
Debes proporcionar un nombre de archivo para restaurar. ¿Querías decir uno de los siguientes?
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
Off: ¿hay alguna forma de resaltar líneas en bloques de código?
Bueno, por lo general, /var/discourse/shared/standalone/backups es el directorio que es visible en tu contenedor como /var/www/discourse/public/backups (de ahí la palabra shared). Tu comando rsync está guardando la copia de seguridad dentro de ese directorio para hacerla accesible desde dentro del contenedor.
A la inversa, si el contenedor escribe en public/backups, debería ser visible en tu host en el directorio compartido.
Escribí /var/discourse/shared... más arriba. Pero parece que estás trabajando en ~/infra/discourse, por lo que estás copiando a ~/infra/discourse/shared/standalone/backups/default.
Por lo general, el contenedor está mapeado a /var/discourse/shared/...
Esto podría ser el problema. ¿Puedes verificar si tienes un /var/discourse/shared?
Sin embargo, si entro en la máquina Docker, está allí
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
Así que mi pregunta: si creo una copia de seguridad, ¿debería verla desde fuera de Docker?
Mientras tanto, acabo de crear una máquina vagrant y hacer un git clone desde dentro en el directorio estándar /var/discourse. Lo único “extraño” es que tengo un discourse.yml dentro del contenedor, no app.yml.
Sí, y esto es lo mismo que tu problema original:
“si tienes una copia de seguridad fuera de Docker y la colocas en el directorio compartido, deberías poder verla dentro de Docker” (y no puedes).
El problema está en tus directorios compartidos y se debe a esto:
Me refería a que, por ahora, he recreado una máquina Vagrant totalmente nueva, sin copiar ninguna copia de seguridad anterior. Ejecuté el proceso de inicialización y arranqué el contenedor de Docker. Luego realicé la copia de seguridad.
No se ve nada en la máquina Vagrant fuera de la máquina de Docker.
Creo que he encontrado el problema: he montado esta carpeta compartida de Docker en la máquina Vagrant que la contiene.
Si comento esto en mi archivo Vagrantfile, las copias de seguridad “mágicamente” aparecen.
El problema era que la carpeta compartida de Vagrant (para “subir”) y la carpeta compartida de Docker (para “bajar”) entran en conflicto y hacen que sea inválido.
