Ho avuto alcuni problemi con l’aggiornamento: il primo forum ha fallito al primo tentativo (tramite la dashboard), poi è fallito di nuovo con un rebuild, ma sembra che abbia funzionato al secondo tentativo di rebuild, anche se poi ho dovuto eseguire un altro rebuild. Questo mi ha ricordato che dovevo fermare tutte le istanze di Discourse durante l’aggiornamento con PG12 (su questo server ci sono tre forum Discourse con container separati) e quindi quanto segue ha funzionato per gli altri due forum:
Tuttavia, per qualche motivo, il primo forum non è più accessibile: Safari segnala che il server ha interrotto improvvisamente la connessione. Eseguire un rebuild sembra andare a buon fine, ma il forum non è accessibile; posso accedere all’app e alla console Rails e il database sembra integro.
Gli unici avvisi che riesco a vedere durante il rebuild che potrebbero essere rilevanti sono:
168:M 31 Gen 2021 21:39:22.459 # WARNING: La configurazione TCP backlog di 511 non può essere applicata perché /proc/sys/net/core/somaxconn è impostato sul valore inferiore di 128.
168:M 31 Gen 2021 21:39:22.459 # Server inizializzato
168:M 31 Gen 2021 21:39:22.459 # WARNING: overcommit_memory è impostato a 0! Il salvataggio in background potrebbe fallire in condizioni di bassa memoria. Per risolvere questo problema, aggiungi 'vm.overcommit_memory = 1' a /etc/sysctl.conf e poi riavvia oppure esegui il comando 'sysctl vm.overcommit_memory=1' affinché abbia effetto.
168:M 31 Gen 2021 21:39:22.459 # WARNING: hai abilitato il supporto Transparent Huge Pages (THP) nel tuo kernel. Questo creerà problemi di latenza e utilizzo della memoria con Redis. Per risolvere questo problema, esegui il comando 'echo madvise > /sys/kernel/mm/transparent_hugepage/enabled' come root e aggiungilo al tuo /etc/rc.local per mantenere l'impostazione dopo un riavvio. Redis deve essere riavviato dopo aver disabilitato THP (impostato su 'madvise' o 'never').
168:M 31 Gen 2021 21:39:22.459 * Caricamento RDB prodotto dalla versione 6.0.9
168:M 31 Gen 2021 21:39:22.459 * Età RDB: 21 secondi
168:M 31 Gen 2021 21:39:22.459 * Utilizzo memoria RDB al momento della creazione: 4.03 Mb
168:M 31 Gen 2021 21:39:22.466 * DB caricato dal disco: 0.006 secondi
168:M 31 Gen 2021 21:39:22.466 * Pronto ad accettare connessioni
production.log:
Eccezione Job: Errore di connessione a Redis su localhost:6379 (Errno::ENETUNREACH)
Errore di connessione a Redis su localhost:6379 (Errno::ENETUNREACH) sottoscrizione fallita, riconnessione tra 1 secondo. Stack di chiamate /var/www/discourse/vendor/bundle/ruby/2.7.0/gems/redis-4.2.5/lib/redis/client.rb:367:in `rescue in establish_connection'
Messaggi simili appaiono in unicorn.stderr.log e unicorn.stdout.log.
Entrando nel container ed eseguendo redis-cli ping ottengo una risposta PONG. Redis è in esecuzione sul server (ma non nei container individuali - anche se questo è sempre stato così, per quanto ne so).
Avete qualche idea su cosa possa star succedendo?
(Ho anche riavviato il server e creato un nuovo certificato letsencrypt per questo dominio per stare tranquillo, ma il problema persiste.)
Alcune possibili cause dell’errore di risposta vuota:
Il server si trova in una VPN e non c’è accesso alla porta.
Se hai più istanze di Discourse sullo stesso server, presumo ci sia un reverse proxy davanti. Assicurati che punti al contenitore di Discourse (potrebbe essere necessario riavviarlo).
Non c’è abbastanza spazio sul server (puoi eseguire df -hT /).
Inizierei controllando prima lo spazio su disco libero (3).
L’utilizzo del disco era al 31%, ma ho comunque eseguito ./launcher cleanup:
docker container ls
(Per assicurarsi che tutti e tre i container del forum siano in esecuzione)
./launcher cleanup
ATTENZIONE! Verranno rimossi tutti i container fermi.
Sei sicuro di voler continuare? [y/N] y
Spazio totale recuperato: 0B
ATTENZIONE! Verranno rimosse tutte le immagini senza almeno un container associato.
Sei sicuro di voler continuare? [y/N] y
Immagini eliminate:
...
Spazio totale recuperato: 32,56 GB
Utilizziamo HAProxy e l’ho controllato (e riavviato): è attivo e funzionante (gestiamo anche il reindirizzamento da http a https tramite di esso, che funziona correttamente anche per il dominio, quindi non credo sia un problema lì; inoltre, funzionava fino a questo aggiornamento).
Posso ancora accedere al container e usare la console di Rails; il DB è ancora lì e connesso al container. Quindi la situazione è estremamente strana. Qualcuno ha altre idee o passaggi aggiuntivi per risolvere il problema?
Se non sei riuscito a individuare il problema, un’opzione potrebbe essere eseguire un backup da riga di comando e ripristinarlo su un nuovo sito fresco in esecuzione su PG13. In alternativa, se hai bisogno che il tuo sito torni operativo, puoi revertare la versione a PG12, spostare la directory esistente shared/postgres_data_old nuovamente in shared/postgres_data e ricostruire. Tuttavia, ti consigliamo di provare prima l’opzione backup/ripristino, poiché il problema non sembra essere correlato all’aggiornamento del database stesso.
Se hai altre idee per indagare su questo problema, sono felice di provarle, Michael. Fortunatamente non è un grosso problema che il forum sia offline, dato che era comunque in modalità sola lettura (essendo stato sostituito da un altro forum).
Se non hai altre idee, procederò con il tentativo di ripristinare un backup, ma se possibile vorrei risolvere il problema, poiché sono interessato a capire perché è successo (come immagino tu possa esserlo). Quindi sono assolutamente disponibile a indagare ulteriormente se lo sei anche tu.
A dire il vero, mi ha messo un po’ di ansia convertire alcuni dei miei altri forum in Discourse, e sapere cosa è andato storto potrebbe esserci utile a tutti noi.
È un’installazione standard a più container in cui ogni forum ha il proprio file app.yml e una configurazione di container basata su host: discourse/shared-site-name/standalone e host: discourse/shared-site-name/standalone/log/var-log (come indicato dalle domande che ho posto e dai post su questo forum).
Accedendo a ogni container ed eseguendo psql (sudo -u postgres psql discourse) e \l+, si vede solo un database discourse per container (e ciascuno ha dimensioni diverse), quindi immagino che si tratti di istanze di Discourse indipendenti.
Hai un link al metodo standard per eseguire più forum Discourse indipendenti su un server? Posso verificare se corrisponde a quanto ho io, anche se sono abbastanza sicuro che la mia configurazione si basi su post e indicazioni del team di Discourse.
Stai eseguendo nginx all’interno del contenitore? Il prossimo passo che suggerirei è verificare dove stanno arrivando le richieste. Quindi, se ho capito bene, hai HAProxy che gestisce la terminazione SSL e poi inoltra le richieste ai rispettivi contenitori?
Per quanto ne sappia, i container stessi sono tutti “standard” (quindi, da quanto ho capito, ognuno esegue nginx) e sì, HAProxy gestisce tutto il traffico SSL e indirizza le richieste a ciascun container.
C’era un problema con la configurazione di HAProxy:
backend main_apache_sites
server server1 127.0.0.1:8080 cookie A check
cookie JSESSIONID prefix nocache
backend discourse_docker
server server2 127.0.0.1:8888 cookie A check
cookie JSESSIONID prefix nocache
backend discourse_docker_2
server server2 127.0.0.1:8889 cookie A check
cookie JSESSIONID prefix nocache
backend discourse_docker_3
server server2 127.0.0.1:8890 cookie A check
cookie JSESSIONID prefix nocache
backend letsencrypt-backend
server letsencrypt 127.0.0.1:54321
Per qualche motivo, tutti i backend di Discourse avevano server2 nella seconda riga. Ieri ho modificato questi valori in server2, server3, ecc., ma non ha fatto alcuna differenza (e in precedenza funzionava perfettamente così).
Ci sono file di log specifici a cui potrei fare riferimento per ottenere ulteriori indicazioni? Forse i file di log di Docker?
Sì, sono commentati:
templates:
- "templates/postgres.template.yml"
- "templates/redis.template.yml"
- "templates/web.template.yml"
- "templates/web.ratelimited.template.yml"
## Scommenta queste due righe se desideri aggiungere Lets Encrypt (https)
#- "templates/web.ssl.template.yml"
#- "templates/web.letsencrypt.ssl.template.yml"
I log di nginx all’interno dei container dell’applicazione dovrebbero essere in grado di confermare che le richieste stanno raggiungendo l’applicazione; puoi controllarli? nginx nel container inoltra le richieste a 127.0.0.1:3000, che punta al processo unicorn.
Ho controllato in /var/log/nginx e /shared/log/rails, ma non emerge nulla di significativo. In effetti, nessuno dei log è stato aggiornato oggi (il 4), tranne /shared/log/rails/production.log, che contiene solo alcune attività come questa:
Ho anche modificato la porta in HAProxy e, come previsto, ho ottenuto un errore “server non trovato”. Ho poi aggiornato il container alla stessa porta e il comportamento è tornato allo stato precedente (quindi penso che questo escluda un problema legato a HAProxy).
Ci sono log Docker da controllare? Oppure posso salvare/esportare questo container e inviartelo così da poterlo esaminare? Immagino che tu ti stia chiedendo cosa sia andato storto tanto quanto me
Nessuno dei log di nginx è stato modificato oggi, anche se l’ultimo log del 30 gennaio mostra: 7: limiting requests by zone “flood” client: my.ip.address, POST /mini-profiler-resources tipo di errore.
Modifica: non so se questo sia utile, ma eseguendo docker logs APP:
# docker logs f2
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
run-parts: executing /etc/runit/1.d/cleanup-pids
Cleaning stale PID files
run-parts: executing /etc/runit/1.d/copy-env
Started runsvdir, PID is 42
ok: run: redis: (pid 55) 0s
ok: run: postgres: (pid 54) 0s
chgrp: invalid group: 'syslog'
supervisor pid: 51 unicorn pid: 82
(51) Reopening logs
(51) Reopening logs
(51) Reopening logs
(51) Stopping Sidekiq
(51) Reloading unicorn (82)
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid... 22039
(51) Old pid is: 82 New pid is: 22039
(51) Stopping Sidekiq
(51) Reloading unicorn (22039)
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid...
(51) Waiting for new unicorn master pid... 23358
(51) Old pid is: 22039 New pid is: 23358
(51) Reopening logs
(51) Reopening logs
Per il forum tre (che funziona anch’esso correttamente):
Analizzando i log e rileggendo le tue risposte precedenti, l’applicazione sta tentando di accedere a Redis su localhost:6379 all’interno del container, e sembra che Redis si avvii correttamente; tuttavia, per qualche motivo, non riesce a connettersi (puzzante). È possibile comunque che questi messaggi di errore provengano dal momento in cui message_bus tenta di connettersi prima che Redis si avvii, o dopo che si arresta in caso di riavvio.
Hai menzionato che Redis è in esecuzione sul server ma non nei singoli container: potresti spiegare meglio?
Con questa configurazione, Redis verrà eseguito all’interno del container (come si può vedere nell’output dei log di Docker).
A proposito, quando navighi all’URL del sito che non funziona, cosa appare nei log di nginx? error.log dovrebbe essere vuoto, mentre access.log dovrebbe essere pieno di varie richieste HTTP. Sto solo cercando di capire in quale punto esattamente qualcosa va storto.
Scusa, ho fatto confusione. In realtà Redis funziona in ogni container, come verificato eseguendo questi comandi direttamente sul server e poi in ciascuno dei tre container di Discourse, ottenendo lo stesso output per tutti:
$ redis-cli ping
PONG
$ redis-server
# Creating Server TCP listening socket *:6379: bind: Address already in use (means it's already started)
$ redis-cli
127.0.0.1:6379> ping
PONG
127.0.0.1:6379> get mykey
(nil)
127.0.0.1:6379> set mykey somevalue
OK
127.0.0.1:6379> get mykey
"somevalue"
Lo stesso vale per tutti e tre (da notare: il primo get mykey restituisce sempre nil), quindi possiamo affermare con sicurezza che Redis è attivo e in esecuzione in modo indipendente in tutti i container.
È vuoto e non è stato scritto nulla in quella directory oggi:
drwxr-xr-x 2 www-data www-data 4096 Feb 4 21:26 .
drwxrwxr-x 9 root root 4096 Feb 2 08:03 ..
-rw-r--r-- 1 www-data www-data 0 Feb 3 07:38 access.log
-rw-r--r-- 1 www-data www-data 0 Feb 2 08:03 access.log.1
-rw-r--r-- 1 www-data www-data 294 Feb 1 09:43 access.log.2.gz
-rw-r--r-- 1 www-data www-data 37598 Jan 30 23:56 access.log.3.gz
-rw-r--r-- 1 www-data www-data 58059 Jan 30 07:36 access.log.4.gz
-rw-r--r-- 1 www-data www-data 55988 Jan 29 07:34 access.log.5.gz
-rw-r--r-- 1 www-data www-data 73964 Jan 28 07:49 access.log.6.gz
-rw-r--r-- 1 www-data www-data 78069 Jan 27 07:53 access.log.7.gz
-rw-r--r-- 1 www-data www-data 0 Feb 3 07:38 error.log
-rw-r--r-- 1 www-data www-data 0 Feb 2 08:03 error.log.1
-rw-r--r-- 1 www-data www-data 20 Feb 1 00:31 error.log.2.gz
-rw-r--r-- 1 www-data www-data 632 Jan 30 23:46 error.log.3.gz
-rw-r--r-- 1 www-data www-data 265 Jan 29 09:07 error.log.4.gz
-rw-r--r-- 1 www-data www-data 20 Jan 28 07:50 error.log.5.gz
-rw-r--r-- 1 www-data www-data 3107 Jan 28 07:41 error.log.6.gz
-rw-r--r-- 1 www-data www-data 20 Jan 26 07:53 error.log.7.gz
Ho controllato i log di accesso di un altro container e va tutto bene, quindi il problema è solo in questo.
Sembra che HAProxy stia inoltrando la richiesta, ma il container non riesce a gestirla o accettarla. Mi chiedo se ci sia qualcosa che possa essere resettato lì? (Pensavo che ricreare il container avrebbe già dovuto farlo, no?)
IMAGE COMMAND CREATED STATUS PORTS
local_discourse/1 "/sbin/boot" 20 ore fa In esecuzione da 20 ore 0.0.0.0:2225->22/tcp, 0.0.0.0:8892->80/tcp
local_discourse/2 "/sbin/boot" 4 giorni fa In esecuzione da 4 giorni 0.0.0.0:2223->22/tcp, 0.0.0.0:8889->80/tcp
local_discourse/3 "/sbin/boot" 4 giorni fa In esecuzione da 4 giorni 0.0.0.0:2224->22/tcp, 0.0.0.0:8890->80/tcp
Il mio istinto mi dice che è legato al tentativo fallito tramite la dashboard: di solito, per aggiornamenti di PostgreSQL o aggiornamenti importanti, la dashboard indica che è necessario eseguire una ricompilazione e che l’aggiornamento è disabilitato tramite la dashboard stessa. Tuttavia, per qualche motivo non è successo (forse perché non aggiornavo quel forum da un po’ di tempo, quindi pensavo di doverlo fare prima tramite la dashboard) oppure potrebbe non essersi spento o avviato correttamente prima di eseguire la ricompilazione
Nel file di configurazione di HAProxy, vedo che i backend sono configurati per inoltrare le richieste alle porte 8888, 8889 e 8890:
Tuttavia, i container dell’applicazione sono in ascolto sulle porte 8892, 8889 e 8890 - sembra esserci una discrepanza per il backend discourse_docker. È qualcosa che hai aggiornato nella configurazione da quando è stato pubblicato quel messaggio?
Sì, le porte di HAProxy corrispondono alle porte corrette del contenitore Sono abbastanza sicuro che non c’entri con questo, dato che funzionava perfettamente; è successo solo dopo quell’aggiornamento/ricostruzione.
Entrare nel contenitore, aprire le statistiche Top e poi andare al sito non sembra fare alcuna differenza. Nel caso possa essere utile, ecco uno screenshot:
Sono abbastanza sicuro che non c’entri con questo, dato che funzionava perfettamente; è successo solo dopo quell’aggiornamento/ricostruzione.