Sto eseguendo Discourse in un cluster Kubernetes da un po’ di tempo utilizzando l’immagine Bitnami non supportata. Ora che Bitnami sta deprecando l’immagine e passando a un paywall, sto cercando di migrare il nostro server a una soluzione self-hosted su AWS.
Ho alcune domande per le quali sarei grato se la community potesse aiutarmi:
Utilizziamo già un database Postgres esterno per l’installazione e questo rimarrà in loco. Tuttavia, abbiamo aggiornato alcune impostazioni tramite l’interfaccia utente e anche utilizzando variabili d’ambiente che gli script di installazione Bitnami mappano a Discourse, ad esempio DISCOURSE_S3_BACKUP_BUCKET viene mappato a S3_BACKUP_BUCKET.
È sufficiente impostare le impostazioni di Discourse nei file yaml richiesti o dovremmo comunque utilizzare le variabili d’ambiente?
Se effettuiamo un backup dall’interfaccia utente, cosa verrà effettivamente ripristinato? Aggiorna il database?
È meglio creare un database completamente nuovo con un’installazione pulita e poi eseguire un backup/ripristino?
Se la nuova installazione è una versione successiva di Discourse, ciò causerà un problema se si tenta un ripristino?
La guida all’installazione standard utilizza Docker: come si monitorano i container in un ambiente di produzione poiché sembra che l’installazione standard sia una singola VM con Docker.
Ci sono documenti che dettagliano una migrazione e eventuali problemi?
Sono sicuro che avrò altre domande man mano che la migrazione procederà, ma qualsiasi consiglio/aiuto che possa essere fornito sarebbe molto apprezzato.
Se per “meglio” intendi “questo farà sì che io non interrompa il nostro sito esistente e lo lasci in uno stato in cui non funzionerà mai più?”, la risposta è sì.
È quello che vuoi. Il luogo da cui ripristini deve essere uguale o più recente della versione di backup. Migrerà il database dopo il ripristino.
Questo potrebbe essere tutto ciò che devi sapere e siamo felici di aiutarti qui gratuitamente. Se desideri un’attenzione pratica specifica per la tua configurazione, puoi contattarmi o chiedere aiuto in Marketplace.
Inoltre, un’altra opzione sarebbe quella di creare immagini e avviarle in k8s. L’ho fatto alcune volte e ho utilizzato github per creare le immagini.
La mia esperienza concorda. Ho visto così tanti piccoli e strani fallimenti nel corso degli anni che mantengo sempre backup completi in modo da poter ricominciare da capo e ripristinare il sito. Affidarsi alla correzione dei problemi in situ alla fine ti deluderà.
Come te, sono rimasto bloccato quando Bitnami ha smesso di offrire immagini e grafici gratuiti. Ho dovuto adattare e migrare così tante distribuzioni. Una di queste era la mia distribuzione Discourse. Se ti è utile, ecco un link al grafico Helm sostitutivo che ho creato in pochissimo tempo (il che significa che funziona ma è tutt’altro che un design ideale). È un tentativo di utilizzare il “metodo di installazione ufficiale” dato che non ho visto emergere alcun grafico Helm “standard della community” dopo tutti questi anni. (Suppongo che il grafico di Bitnami fosse di fatto quello standard, perché pochi di noi hanno previsto questo brusco cambiamento.) In ogni caso, questo nuovo grafico che sto eseguendo per una delle mie comunità di ricerca è fondamentalmente solo un pod con due container: il container Docker-in-Docker ufficiale e un container personalizzato basato su python:3, che installa Docker e poi utilizza l’installazione ufficiale di Discourse. Poiché tutti i componenti (server Discourse, Redis, PostgreSQL) vengono eseguiti nella scatola nera dell’immagine creata localmente dallo script di avvio, non c’è scalabilità o supporto per l’alta disponibilità. Sono riuscito a ridurre il tempo di inattività dovuto al riavvio del pod su un altro nodo (ad esempio, durante il drenaggio del nodo per aggiornamenti del sistema operativo o un crash del nodo) utilizzando docker save per archiviare l’immagine creata sul volume persistente, e quindi caricandola se local_discourse/app:latest non viene trovato.
Ma per rispondere alla tua domanda, non so come monitorare nulla in questa nuova distribuzione. Sto eseguendo “in produzione” ma la mia comunità è abbastanza piccola e l’utilizzo è abbastanza moderato che se il forum va offline per un po’, non è un grosso problema. Anche così, sono molto vicino ad abbandonare l’auto-hosting e migrare a un servizio come Communiteq o Discourse.org.