Configurazione Discourse HA in ambiente di rete isolato

Grazie in anticipo.
Sto pianificando l’installazione di Discourse con alta disponibilità in un ambiente di produzione. Di seguito sono riportati il mio piano di progettazione e alcune condizioni ambientali.

  1. Installazione con 3 server applicativi e 2 server DB Postgres. Sempre un server PG in modalità di scrittura e un altro in modalità di sola lettura.

  2. Questi 3 server applicativi punteranno allo stesso server DB.

  3. Ogni istanza del DB dovrebbe servire rispettivamente operazioni di sola lettura e di scrittura.

  4. I server di produzione non hanno connettività Internet, ma posso scaricare immagini da dockerHub.

  5. Abbiamo il nostro server GitLab.

  6. È possibile avviare un’immagine Docker e distribuirla su più server?

Qualcuno può aiutarmi a realizzare questa configurazione? Se ci sono link o suggerimenti, per favore inviatemi un messaggio privato.

2 Mi Piace

Dopo aver eseguito ./launcher bootstrap app da qualche parte, dovrai salvare l’immagine del container risultante (solitamente fatto inviandola a un registro) e quindi scaricarla ed eseguirla sui tuoi tre server dell’applicazione.

Avrai anche bisogno di un server Redis centrale (e potenzialmente delle sue repliche). Ti manca anche un load balancer per indirizzare le richieste a quei diversi server dell’applicazione.

3 Mi Piace

Grazie per la risposta @Falco

Stiamo utilizzando HAProxy come load-balancer e Nexus repo per l’archiviazione degli artefatti.

1 Mi Piace

Ciao @Falco
Nel mio ambiente di produzione, non ho accesso a Internet, quindi quello che sto pianificando è eseguire il bootstrap su una macchina accessibile da Internet, portando quell’immagine di bootstrap sui server di produzione. Mentre lo faccio sulla VM di produzione, il container non si avvia perché il server Unicorn cerca un ID di processo padre, quindi non è in esecuzione.
Per favore, aiutami qui, devo copiare la directory /var/discourse dopo il bootstrap sul server di produzione?

Cos’è “questo”? Il bootstrap o l’esecuzione dell’immagine del container precedentemente avviata?

1 Mi Piace

Quando eseguo l’immagine container precedentemente avviata

Come hai salvato ed esportato l’immagine sul server di produzione?

Come, esattamente, stai cercando di eseguire questa immagine salvata in produzione?

1 Mi Piace

immagine precedentemente avviata che invia al repository Nexus e dal repository Nexus che estrae sul server di produzione.

comando docker run generato da ./launcher start-cmd app ed esecuzione dello stesso comando sul server di produzione.

1 Mi Piace

Puoi condividere il log degli errori all’avvio in produzione?

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
chgrp: invalid group: ‘syslog’
ok: run: redis: (pid 51) 0s
ok: run: postgres: (pid 56) 0s
supervisor pid: 53 unicorn pid: 75
config/unicorn_launcher: line 71: kill: (75) - No such process
config/unicorn_launcher: line 15: kill: (75) - No such process
(53) exiting
ok: run: redis: (pid 51) 7s
ok: run: postgres: (pid 101) 0s
supervisor pid: 96 unicorn pid: 103
config/unicorn_launcher: line 71: kill: (103) - No such process
config/unicorn_launcher: line 15: kill: (103) - No such process
(96) exiting
ok: run: redis: (pid 51) 14s
ok: run: postgres: (pid 127) 0s
supervisor pid: 120 unicorn pid: 129
config/unicorn_launcher: line 71: kill: (129) - No such process
config/unicorn_launcher: line 15: kill: (129) - No such process
(120) exiting
ok: run: redis: (pid 51) 22s
timeout: down: postgres: 0s, normally up, want up
ok: run: redis: (pid 51) 30s
timeout: down: postgres: 1s, normally up, want up
ok: run: redis: (pid 51) 37s
ok: run: postgres: (pid 174) 0s
supervisor pid: 165 unicorn pid: 176
config/unicorn_launcher: line 71: kill: (176) - No such process
config/unicorn_launcher: line 15: kill: (176) - No such process
(165) exiting
ok: run: redis: (pid 51) 48s
ok: run: postgres: (pid 196) 1s
supervisor pid: 191 unicorn pid: 198
config/unicorn_launcher: line 71: kill: (198) - No such process
config/unicorn_launcher: line 15: kill: (198) - No such process
(191) exiting
ok: run: redis: (pid 51) 54s
timeout: down: postgres: 1s, normally up, want up

Stai utilizzando PostgreSQL, Redis e Object Storage esterni? Questo è previsto quando si esegue l’alta disponibilità (HA) e sia i server di produzione che i server di build devono avere accesso a tali servizi esterni.

Sto solo testando lo scenario, bootstrap che esegue su un server ed esegue l’immagine container avviata su un altro server con configurazione standalone.

È un modo sicuro che non funzionerà.

C’è un motivo per menzionare lo storage degli oggetti, non possiamo usare lo storage interno del server?

Nella configurazione HA è necessario copiare la directory discourse eseguita con bootstrap su tutti i server delle applicazioni?

Come gestirai più server di applicazioni e caricamenti degli utenti? Un’unità di rete condivisa tra tutti i server? Potrebbe funzionare, ma la nostra soluzione ufficiale per questo è Object Storage utilizzando l’API S3.

Non è necessario, purché tu

Sì, sto usando un server Postgres esterno e un cluster Redis

3 server di applicazioni utilizzati per il cluster Redis insieme all’applicazione.

Quindi devo usare una directory/storage condivisa per la directory di build di Discourse. Grazie @Falco, ora mi è chiaro.

Mi dispiace disturbarti @Falco, ho un’ultima domanda.

Durante l’esecuzione del passaggio di rebuild, ciò avrà un impatto sui dati esistenti nel database Postgres? Se sì, come gestirlo?

Sì, ci sono migrazioni che verranno eseguite durante una ricostruzione, che cambieranno sia i dati che la struttura.

In un ambiente HA dovrai seguire la guida che abbiamo qui: Introducing Post Deployment Migration

1 Mi Piace

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.