Non dimenticare di eseguire docker remove app quando reinstalli discourse

Supporto
1

Utilizzo Discourse da diversi anni. Ogni 6 mesi imposto una nuova istanza. La mia configurazione include Docker e un proxy basato su Nginx, quindi è forse leggermente non standard. Per questo motivo non utilizzo discourse-setup.

Ogni 6 mesi, quando ripeto questo processo, dopo aver clonato una copia fresca di Discourse dal suo git ed eseguito ./launcher bootstrap app, il container non si avvia. Il log mostra:

anacron: Can't chdir to /var/spool/anacron: No such file or directory
run-parts: /etc/runit/1.d/anacron exited with return code 1
run-parts: executing /etc/runit/1.d/00-ensure-links
run-parts: executing /etc/runit/1.d/00-fix-var-logs
run-parts: executing /etc/runit/1.d/01-cleanup-web-pids
run-parts: executing /etc/runit/1.d/anacron
anacron: Can't chdir to /var/spool/anacron: No such file or directory

ad infinitum.

Di solito eseguo una serie di passaggi per riavviare, rimuovere plugin, riaggiungerli, ecc., finché non funziona, senza mai capire cosa alla fine lo abbia fatto funzionare. 6 mesi dopo, succede la stessa cosa. Lavoro solo per risolverlo, e non è chiaro quale dei molti passaggi che eseguo alla fine lo abbia fatto funzionare.

Questa volta, però, credo di aver finalmente trovato il problema, ed è questo: apparentemente, ./launcher start app riavvia vecchie istanze del container chiamate app, anche quando Discourse è stato clonato e riavviato.

Il passaggio mancante è docker remove app. In sintesi:

./launcher stop app
docker remove app
... ora la clonazione, il riavvio e `launcher start app` funzionano

Il mio errore è stato aspettarmi che dopo aver eseguito ./launcher bootstrap app, il successivo ./launcher start app avviasse la nuova immagine del container, ma non sembra essere così. Naturalmente, le cose vanno a rotoli con la vecchia poiché il percorso /var/discourse/shared è stato reinizializzato.

Lascio questo qui nel caso in cui altri cerchino gli stessi messaggi di errore nel log.

Come possibile miglioramento, sarebbe bello se il container rilevasse che la sua directory /var/discourse/shared è cambiata.

2 Mi Piace
2

Se vuoi eseguire il bootstrap, il “modo discourse” è

./launcher bootstrap app
./launcher destroy app
./launcher start app

Ma se hai solo un container, non c’è motivo di non fare semplicemente

./launcher rebuild app

come quasi tutti gli esempi dicono. Questo ferma il container in esecuzione, esegue il bootstrap di uno nuovo e lo avvia. Se il bootstrap fallisce per qualche motivo, puoi (di solito) riavviare quello vecchio con ./launcher start app (come hai descritto).

3

Penso di aver individuato il problema, ed è correlato alla solita confusione tra “istanza di container” e “immagine di container”.

Se si guarda, ad esempio, a 10. Post-Install Maintenance, si legge:

Usage: launcher COMMAND CONFIG [--skip-prereqs] [--docker-args STRING]
Commands:
    start:      Avvia/inizializza un container
    stop:       Arresta un container in esecuzione
    restart:    Riavvia un container
    destroy:    Arresta e rimuove un container
    enter:      Utilizza nsenter per ottenere una shell in un container
    logs:       Visualizza i log di Docker per un container
    bootstrap:  Avvia un container per la configurazione basata su un template
    rebuild:    Ricostruisce un container (distrugge il vecchio, avvia il nuovo)
    cleanup:    Rimuove tutti i container che sono stati arrestati per più di 24 ore

Nella maggior parte degli usi della parola “container” in questo output di aiuto, si riferisce a un’istanza di un container. Tranne in bootstrap, dove si riferisce a un’immagine. (./launcher bootstrap utilizza docker commit per creare una nuova immagine da cui possono essere avviate le successive istanze di container.) Penso che questo fosse inaspettato (e ingenuamente ho presunto che avrebbe interessato anche l’istanza app corrente.)

In rebuild, la parola container si riferisce sia alle immagini di container che alle istanze poiché comporta una serie di operazioni che interessano sia le istanze di container che le immagini di container.

E non è chiaro a cosa si riferisca in cleanup: verranno rimosse solo le istanze o anche l’immagine avviata?

1 Mi Piace