Basandomi sul repository discourse_docker, ho scritto un piccolo script per automatizzarne l’utilizzo all’interno di una macchina vagrant (eseguita con set -x per vedere cosa viene effettivamente fatto)
Ho copiato il backup nella posizione sbagliata?
E cosa significa la riga di log Assicurarsi che /var/www/discourse/tmp/restores/default/2020-05-13-190832 esista...?
~/infra/discourse su master! ⌚ 21:14:07
$ pwd
/home/pihentagy/infra/discourse
~/infra/discourse su master! ⌚ 21:01:14
$ ./wl.sh start
+ set -e
+ VAGRANT_MACHINE_NAME=guest
+ cd discourse
+ case "$1" in
+ init
+ printf 'Checkout e aggiornamento del repository…\n'
Checkout e aggiornamento del repository…
+ cd ..
+ git clone https://github.com/discourse/discourse_docker.git discourse
fatal: il percorso di destinazione 'discourse' esiste già e non è una directory vuota.
+ printf 'Repository già presente\n'
Repository già presente
+ cd discourse
+ printf 'Aggiornamento del repository…\n'
Aggiornamento del repository…
+ git pull -r
remote: Enumerazione degli oggetti: 6, completata.
remote: Conteggio degli oggetti: 100% (6/6), completato.
remote: Compressione degli oggetti: 100% (4/4), completata.
remote: Totale 6 (delta 2), riutilizzati 5 (delta 2), pack riutilizzati 0
Decompressione degli oggetti: 100% (6/6), completata.
Da https://github.com/discourse/discourse_docker
3e465a2..49ed141 master -> origin/master
Autostash creato: 36aae80
HEAD ora su 3e465a2 Rimuovere tutte le tracce di pg12 in modo che pg_wrapper non si confonda
Per prima cosa, riavvolgimento della testa per riproporre il tuo lavoro sopra di essa...
Master avanzato rapidamente a 49ed14152971f7f4a7437657987952be44c33c0a.
L'applicazione dell'autostash ha generato conflitti.
Le tue modifiche sono al sicuro nello stash.
Puoi eseguire "git stash pop" o "git stash drop" in qualsiasi momento.
+ printf 'Copia del file di configurazione…\n'
Copia del file di configurazione…
+ cp ../resources/discourse.yml containers/
+ echo 'Avvio della macchina Vagrant...'
Avvio della macchina Vagrant...
+ vagrant up
Avvio della macchina 'dockerhost' con il provider 'virtualbox'...
==> dockerhost: Controllo se la box 'ubuntu/xenial64' è aggiornata...
==> dockerhost: La macchina è già fornita. Esegui `vagrant provision` o usa il flag `--provision`
==> dockerhost: per forzare il provisioning. I provisioner contrassegnati per l'esecuzione sempre verranno comunque eseguiti.
+ vagrant ssh -c 'cd /vagrant;sudo ./launcher start discourse'
2627afdfbaac
Niente da fare, il tuo container è già avviato!
Connessione a 127.0.0.1 chiusa.
+ exit 0
~/infra/discourse su 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,41 MB/s 0:00:01 (xfr#1, to-chk=0/1)
inviati 390.870.133 byte, ricevuti 35 byte, 156.348.067,20 byte/sec
totale dimensione 390.774.609, velocità 1.00
+ vagrant ssh -c 'sudo docker exec -w /var/www/discourse -i discourse discourse enable_restore'
Il ripristino è ora consentito. Disabilitalo con `disable_restore`
Connessione a 127.0.0.1 chiusa.
+ vagrant ssh -c 'sudo docker exec -w /var/www/discourse -i discourse discourse restore'
Devi fornire un nome di file da ripristinare. Intendevi uno dei seguenti?
Connessione a 127.0.0.1 chiusa.
+ vagrant ssh -c 'sudo docker exec -w /var/www/discourse -i discourse discourse restore icontest-2020-05-12-033823-v20200506044956.tar.gz'
Avvio del ripristino: icontest-2020-05-12-033823-v20200506044956.tar.gz
[INIZIATO]
'system' ha avviato il ripristino!
Segnatura del ripristino come in corso...
Assicurarsi che /var/www/discourse/tmp/restores/default/2020-05-13-190832 esista...
Copia dell'archivio nella directory tmp...
ECCEZIONE: lib/discourse.rb:90:in `exec': Impossibile copiare l'archivio nella directory tmp.
cp: impossibile accedere a '/var/www/discourse/public/backups/default/icontest-2020-05-12-033823-v20200506044956.tar.gz': File o directory non esistente
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>'
Tentativo di rollback...
Non c'era bisogno di rollback
Pulizia dei file...
Rimozione della directory tmp '/var/www/discourse/tmp/restores/default/2020-05-13-190832'...
Ripresa di sidekiq...
Segnatura del ripristino come completato...
Notifica a 'system' della fine del ripristino...
Completato!
[FALLITO]
Ripristino eseguito.
Connessione a 127.0.0.1 chiusa.
Vagrant non è supportato, ma ecco comunque qualche consiglio.
Non sono sicuro di come funzioni rsync. Il percorso deve terminare con una barra? Se il file finisce nella directory corretta, assicurati che il file copiato sia leggibile dal server.
Quindi vagrant (virtualbox) può causare alcuni problemi?
~/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
Sembra che il file sia leggibile da tutti e si trovi nel posto giusto. Dall’interno del contenitore Docker discourse, dove dovrei vedere il backup? Il mio script di ripristino automatico è corretto o dovrei copiare il file all’interno del contenitore Docker? Se sì, dove? (Forse ci sono guide su come automatizzare Discourse dall’esterno [del 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
[
Non è obbligatorio, ma non terminare il percorso con una barra è una cattiva pratica, poiché il risultato dipende dal fatto che la directory esista già o meno.
Se la directory di destinazione esiste già, non è necessaria una barra e il file viene copiato all’interno della directory.
Se la directory di destinazione non esiste e non c’è una barra alla fine, il file viene copiato in un file chiamato ‘default’.
Se la directory di destinazione non esiste e c’è una barra alla fine, viene creata la directory e il file viene copiato al suo interno.
In questo caso, la copia sembra aver avuto successo (per fortuna).
Tuttavia,
Poiché non ci sono suggerimenti dopo “intendevi uno dei seguenti?”, il file non si trova nel posto giusto. Sembra che le unità siano mappate in modo errato nel container Docker.
Potresti avviare un backup da dentro Docker (discourse backup) e vedere dove finisce nel tuo filesystem host.
Stranamente non è visibile dal filesystem dell’host. Dovrebbe esserlo?
vagrant@ubuntu-xenial:~$ sudo docker exec -w /var/www/discourse -i discourse discourse backup
Avvio del backup...
[IN CORSO]
'system' ha avviato il backup!
Segnatura del backup come in esecuzione...
Verifica dell'esistenza di '/var/www/discourse/tmp/backups/default/2020-05-14-121930'...
Verifica dell'esistenza di '/var/www/discourse/public/backups/default'...
Aggiornamento dei metadati...
Messa in pausa di sidekiq...
In attesa che sidekiq completi i lavori in corso...
Dump dello schema pubblico del database...
…
Molte operazioni pg_dump
…
Riattivazione di sidekiq...
Finalizzazione del backup...
Creazione dell'archivio: discourse-2020-05-14-121930-v20200512064023.tar.gz
Verifica che l'archivio non esista già...
Creazione di un archivio vuoto...
Archiviazione del dump dei dati...
Archiviazione degli upload...
Rimozione della cartella temporanea '/var/www/discourse/tmp/backups/default/2020-05-14-121930'...
Compressione in gzip dell'archivio, potrebbe richiedere del tempo...
Esecuzione dell'hook after_create per il backup...
Cancellazione dei backup vecchi...
Pulizia...
Rimozione dei residui '.tar'...
Segnatura del backup come completato...
Aggiornamento delle statistiche del disco...
Completato!
[SUCCESSO]
Backup eseguito.
Il file di output si trova in: /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 non trovato
vagrant@ubuntu-xenial:~$ sudo docker exec -w /var/www/discourse -i discourse discourse enable_restore
Il ripristino è ora consentito. Disabilitalo con `disable_restore`
vagrant@ubuntu-xenial:~$ sudo docker exec -w /var/www/discourse -i discourse discourse restore
Devi fornire un nome file da ripristinare. Intendevi uno dei seguenti?
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: esiste un modo per evidenziare le righe nei blocchi di codice?
Di solito, /var/discourse/shared/standalone/backups è la directory visibile nel tuo container come /var/www/discourse/public/backups (da qui la parola shared). Il tuo comando rsync sta posizionando il backup all’interno di quella directory per renderlo accessibile all’interno del container.
Viceversa, se il container scrive in public/backups, dovrebbe essere visibile sull’host nella directory condivisa.
Ho scritto /var/discourse/shared... sopra. Ma sembra che tu stia lavorando in ~/infra/discourse, quindi stai copiando in ~/infra/discourse/shared/standalone/backups/default.
Di solito il container è mappato su /var/discourse/shared/...
Questo potrebbe essere il problema. Puoi verificare se esiste /var/discourse/shared?
Vero, ma per ora l’ho semplicemente ignorato. A proposito, quell’rsync è stato eseguito al di fuori della macchina (vagrant) su cui ho eseguito il mio Discourse.
Ma per ora, come hai suggerito, ho fatto quanto segue:
ho eseguito vagrant ssh per accedere alla macchina e, dall’interno:
ho eseguito un backup con sudo docker exec -w /var/www/discourse -i discourse discourse backup
ho notato il percorso del file:
Output file is in: /var/www/discourse/public/backups/default/discourse-2020-05-14-125606-v20200512064023.tar.gz
ho cercato l’intero sistema vagrant per quel file specifico, ma non ho trovato nulla
tuttavia, se entro nella macchina Docker, il file è 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
Quindi la mia domanda: se creo un backup, dovrei vederlo dall’esterno di Docker?
Nel frattempo ho appena creato una macchina vagrant e ho eseguito git clone dall’interno nella directory standard /var/discourse. L’unica “stranezza” è che ho un file discourse.yml all’interno del container, non app.yml.
Sì, ed è la stessa cosa del tuo problema originale:
“se hai un backup fuori da Docker e lo metti nella directory condivisa, dovresti vederlo dentro Docker” (e non lo vedi).
Il problema riguarda le tue directory condivise ed è dovuto a questo:
Volevo dire: per ora ho ricreato una macchina Vagrant completamente nuova, senza copiare alcun backup precedente. Ho eseguito il bootstrap e avviato il contenitore Docker. Ho effettuato il backup.
Niente è visibile nella macchina Vagrant al di fuori della macchina Docker.
Penso di aver individuato il problema: ho montato questa cartella condivisa di Docker nella macchina Vagrant contenente.
Se commento questa riga nel mio file Vagrantfile, i backup “magicamente” riappaiono.
Quindi il problema era che la cartella condivisa di Vagrant (verso l’alto) e la cartella condivisa di Docker (verso il basso) entravano in conflitto, rendendo tutto non valido.
