Problema strano con il nuovo DB Postgres

Ecco un caso che non riesco a risolvere dopo molte installazioni e migrazioni flawless di Discourse.

Contesto:

Avevamo Discourse funzionante correttamente in un container Docker e stavamo lavorando su alcune sfumature del database PostgreSQL.

Il problema si è verificato quando non eravamo soddisfatti dei risultati ottenuti dalla ricottura dei post grezzi; di conseguenza, nulla funzionava come previsto, così abbiamo deciso di eliminare il database PostgreSQL e ricrearlo; ma l’app continuava a restituire vari errori di permessi, ecc.

Poi, abbiamo deciso di “andare sul serio” e di distruggerlo in stile “che ci importa”; siamo quindi entrati direttamente in PostgreSQL (sapendo che probabilmente non sarebbe andato a buon fine, ma volevamo provare) ed abbiamo eliminato tutti i topic e i post dal database (DELETE FROM topics; DELETE FROM posts;). Questo ha funzionato in parte; ma non eravamo soddisfatti dei risultati (fine dell’esperimento), quindi abbiamo deciso di ricostruire Discourse da zero, spostando il vecchio /var/discourse e recuperando una versione fresca da git.

Il Problema

Quando abbiamo costruito un ambiente totalmente nuovo partendo da un git pull, la costruzione è andata a buon fine fino al momento in cui siamo andati sul sito per creare il login dell’amministratore.

Quando abbiamo provato ad accedere come amministratore per una nuova installazione, ci siamo trovati di fronte al vecchio sito che avevamo distrutto! Questa è stata una sorpresa.

Quindi abbiamo deciso di entrare in questa nuova applicazione e provare a eliminare tutte le tabelle di Discourse dal database, cosa che abbiamo fatto; ma, sorpresa, quando abbiamo ricostruito l’app di nuovo, non era un sito fresco, bensì lo stesso sito rotto descritto sopra.

Allora abbiamo eliminato tutte le directory /var/*discourse* e rimosso tutte le immagini Docker, pensando che questo avrebbe garantito una pulizia totale, e abbiamo ricominciato da capo, recuperando da git in /var/discourse e costruendo quello che credevamo fosse da zero assoluto; ma sorpresa… il vecchio sito è ancora lì.

Pensando: “Come è possibile questo?”…??

Abbiamo eseguito ps aux | grep postgres fuori dal container Docker e notato che PostgreSQL esisteva fuori dal container (cosa che ci ha sorpreso, poiché erroneamente pensavamo che l’installazione Docker di Discourse fosse interamente contenuta nel container); quindi abbiamo cercato dove pulire, ma senza successo.

Abbiamo cercato finché i link di Google non sono diventati viola, abbiamo provato di tutto… ma non riusciamo ad ottenere un’installazione pulita di Discourse.

Pensando di aver perso qualcosa, abbiamo provato su un nuovo server, mai utilizzato per installare Discourse, e abbiamo installato Discourse da zero; ha funzionato perfettamente come al solito (un altro server).

La Domanda

La mia domanda è, immagino… quando un’installazione è andata completamente in tilt (in un modo o nell’altro), come possiamo riportare il server, incluso PostgreSQL, allo stato zero iniziale in modo che questo problema scompaia e possiamo avviare un’installazione completamente nuova?

Scusate per un post così lungo, quando forse solo La Domanda sarebbe bastata per ottenere aiuto.

Grazie.

Invece di rimuovere o svuotare le tabelle, elimina semplicemente il database.

Grazie. Proverò e farò sapere i risultati.

Ho provato a eliminare il database, ma continuo a ricevere questo errore di permessi:

/var/www/discourse# su postgres -c 'psql'
psql (10.12 (Debian 10.12-1.pgdg100+1))
Type "help" for help.
postgres=# drop database discourse;
ERROR: database "discourse" is being accessed by other users
DETAIL: There are 3 other sessions using the database.

Qualche idea?

La mia ipotesi migliore è che tu non abbia eliminato il container Docker in esecuzione, ma affermi di aver eliminato le immagini. E sembra che avresti ricevuto qualche altra indicazione.

O stai usando un database PostgreSQL esterno anziché quello contenuto nel container?

Di solito, eliminare /var/discourse/shared ed eseguire una ricostruzione risolve il problema.

Grazie.

Abbiamo appena terminato tutte le sessioni DB discourse precedenti, il che ci ha permesso di eliminare il database discourse.

Ora stiamo eseguendo nuovamente la procedura ./launcher rebuild app. Aggiorniamo con i risultati.

./launch rebuild app non ha funzionato; ecco cosa abbiamo fatto dopo:

Poi:

Building app

WARNING: We are about to start downloading the Discourse base image
This process may take anywhere between a few minutes to an hour, depending on your network speed

Please be patient

Unable to find image ‘discourse/base:2.0.20200220-2221’ locally
2.0.20200220-2221: Pulling from discourse/base
bc51dd8edc1b: Pulling fs layer
27ae5d171719: Pulling fs layer
bc51dd8edc1b: Download complete
bc51dd8edc1b: Pull complete
27ae5d171719: Verifying Checksum
27ae5d171719: Download complete
27ae5d171719: Pull complete
blah blah…
blah blah…
blah blah…


Ancora non funziona dopo un rebuild e un launch senza errori.

Quindi, abbiamo riprovato disattivando l'opzione LETSENCRYPT:

* Optional email address for Let's Encrypt warnings? (Enter 'OFF' to disable.) []: OFF

E sta ancora costruendo l'istanza precedente distrutta (di ore fa) perché in quell'istanza avevamo installato diversi temi, e sono ancora presenti in questa build anche dopo aver ```rimosso``` il database ```discourse```:

Start compiling CSS: 2020-03-15 10:16:20 UTC
Compiling css for default 2020-03-15 10:16:20 UTC
precompile target: desktop Dark
precompile target: mobile Dark
precompile target: desktop_rtl Dark
precompile target: mobile_rtl Dark
precompile target: desktop_theme Dark
precompile target: mobile_theme Dark
precompile target: admin Dark
precompile target: desktop Light
precompile target: mobile Light
precompile target: desktop_rtl Light
precompile target: mobile_rtl Light
precompile target: desktop_theme Light
precompile target: mobile_theme Light
precompile target: admin Light
precompile target: desktop
precompile target: mobile
precompile target: desktop_rtl
precompile target: mobile_rtl
precompile target: desktop_theme
precompile target: mobile_theme
precompile target: admin
Done compiling CSS: 2020-03-15 10:16:27 UTC


Come è possibile che dopo aver eliminato l'intero database ```discourse```, pulito tutte le immagini e i container Docker, cancellato ```rm -rf /var/discourse``` e ricostruito da zero, vediamo ancora tutti i temi installati della build di molte ore fa che stiamo cercando di distruggere completamente?

Non ha senso in un'installazione nuova.

Bene, abbiamo ricominciato da capo, abbiamo commentato i template LETSENCRYPT e l’opzione email, e siamo riusciti a ricostruire correttamente la pagina di accesso dell’amministratore della celebrazione.

Progressi!

Ora modificheremo app.yml e proveremo a riattivare SSL.

Bene. È interessante…

Se ricompilo l’app con SSL (LETS ENCRYPT) abilitato, ottengo due siti diversi…

  • HTTP: Nuovo sito come previsto
  • HTTPS: Vecchio sito rotto

Hmmmm. Questo è davvero sconcertante!

Cosa mostra

 docker ps

?

Prima di ogni build abbiamo eliminato tutte le vecchie immagini Docker, ecc., come segue:

docker system prune -a

Quindi, non si tratta di un problema legato alle immagini Docker.\n
Crediamo che il problema sia legato al certificato SSL LETSENCRYPT; perché quando abbiamo cambiato il sottodominio e generato un nuovo certificato SSL nel processo di build sullo stesso indirizzo IP del server, tutto ha funzionato correttamente; ma quando siamo tornati al sottodominio originale, il problema è rimasto.

Di conseguenza, abbiamo smesso di utilizzare il sottodominio problematico per il momento (era comunque solo un dominio di staging) e abbiamo proseguito.

Grazie per le idee.

Restate al sicuro.

Ma questo cancella solo le immagini non utilizzate. Sei sicuro che non ci siano container in esecuzione?

Sembra che tu abbia più di un contenitore: c’è altro oltre a app.yml nella cartella dei contenitori?

docker ps mostra un solo container in esecuzione e c’è un solo file app.yml in /var/discourse/containers

Grazie comunque per tutte le buone idee!

Molto apprezzato.