Qualcuno potrebbe darmi consigli su come creare un’immagine Docker di Discourse che abbia un certo numero di plugin integrati anziché installarli tramite l’interfaccia utente?
Contesto: vogliamo utilizzare la build di Discourse più recente, ovvero discourse:stable, e da quanto ho letto nella guida all’installazione e in altra documentazione, possiamo prendere questa come immagine di base nel nostro Dockerfile ed eseguire qualcosa come:
RUN cd /var/www/discourse/plugins && \
git clone https://github.com/discourse/discourse-chat-integration.git
Questo aggiungerebbe il plugin discourse-chat-integration alla build. Quindi, al momento dell’esecuzione, possiamo passare tutte le variabili d’ambiente necessarie, ovvero DISCOURSE_HOSTNAME, DISCOURSE_SMTP_DOMAIN, DISCOURSE_DB_HOST ecc., anziché averle codificate nel file app.yml.
Se qualcuno potesse darmi un consiglio in merito, gli sarei molto grato.
Non puoi installare i plugin dall’interfaccia utente. Li installi dal file YML. Se stai usando un container non ancora supportato che non hai costruito tu stesso con launcher, allora faresti qualcosa come suggerisci.
Ma quel plugin è nel core (ma forse non ancora in stable?).
In realtà non sono codificati nel file YML. Il file yml viene utilizzato per costruire e avviare il container. Puoi costruirlo e poi avviarlo tu stesso, come preferisci. Puoi usare ./launcher start-cmd nome-container (o qualcosa del genere, puoi controllare in launcher per vedere se ho sbagliato).
Quindi, penso che tu voglia continuare a usare launcher, aggiungere il plugin, eseguire ./launcher bootstrap app il container, e poi avviarlo come preferisci. Puoi persino caricarlo su un repository da cui puoi avviarlo da qualche altra macchina.
sì, penso che potrebbe non esserci più stable, almeno non per molto. Vedi RFC: A new versioning strategy for Discourse
Quindi, quello che stiamo cercando di fare è eseguire Discourse nel nostro cluster Kubernetes e vorremmo essere in grado di creare l’immagine nel nostro flusso di lavoro CI/CD, da qui il Dockerfile personalizzato. Tutte le variabili d’ambiente vengono quindi fornite al pod in esecuzione in una ConfigMap e/o Secret. So che questa non è un’installazione supportata, ma sto cercando almeno di utilizzare il modo supportato per creare un’immagine Discourse per una versione specifica di Discourse in modo da poter controllare quando aggiorniamo.
Osservando lo script launcher esistente e il file samples/web_only.yml, credo di poter commentare le sezioni volumes e links poiché ciò verrebbe fatto in Kubernetes con un Volume Persistente e un mount. Aggiungeremmo quindi i valori di ambiente fissi in web_only.yml, creeremmo il container con il comando di bootstrap e poi copieremmo l’immagine generata nel nostro repository.
Per quanto riguarda la versione di Discourse, possiamo monitorare quando una nuova release è disponibile su Docker Hub e quindi modificare il valore base_image nel file web.template.yml.
Forse, ma il container ha bisogno di parlare con qualche database per costruire il container, di solito. Non ha bisogno di essere il database effettivo (ma poi devi migrare il database e precompilare gli asset nella tua pipeline).
Potresti confondere il problema degli aggiornamenti di Discourse con gli aggiornamenti delle risorse nel container di base.
Sono riuscito a far compilare il container senza l’hook db:migrate - non sono sicuro che funzionerà perché non l’ho ancora testato - è sulla lista delle cose da fare
Per il valore di base_image - presumo che cambi quando viene rilasciata una nuova immagine docker, quindi penso che prenderò semplicemente quello che è sul branch principale poiché è quello che viene chiamato nello script del launcher.
È un buon inizio! Dovrai comunque eseguire la migrazione del database quando avvii una nuova istanza di Discourse.
Non c’è motivo di ottenere una nuova immagine di base se non stai aggiornando Discourse. Quindi in realtà non ti interessa se ci sono nuove immagini di base.
Grazie Jay. Finalmente la mia build ha funzionato, beh, il pod è partito Ho modificato il mio processo di build CI/CD per includere db:migrate usando un db temporaneo.
db:migrate deve essere sempre eseguito all’avvio dato che la mia build dell’immagine sarebbe contro un db/redis fittizio? Il mio approccio attuale è che db:migrate e la precompilazione verrebbero eseguite in un initContainer nel mio pod.
L’immagine discourse/discourse sarebbe l’ideale da usare se sarà presto pronta per la produzione.
Se sei interessato agli aggiornamenti a zero tempi di inattività, dovresti usare SKIP_POST_DEPLOYMENT_MIGRATIONS e, dopo che i vecchi pod sono terminati, eseguire nuovamente la migrazione con qualcosa come rake db:ensure_post_migrations db:migrate
Al momento sto impostando diverse variabili d’ambiente nel nostro deployment, ad esempio DISCOURSE_BACKUP_LOCATION=s3, e la mia comprensione è che Discourse utilizzerà quel valore piuttosto che quello impostato tramite l’interfaccia utente e quindi memorizzato nella tabella site_settings - è corretto? In tal caso, sono disponibili strumenti/script che mi permettano di verificare quali variabili d’ambiente sono impostate e di determinare il loro equivalente nelle impostazioni del sito?
Perché - sto cercando di migrare un’istanza di Discourse in esecuzione e per aiutare a minimizzare il rischio, volevo non impostare le variabili d’ambiente per ora nel caso ne avessi dimenticata qualcuna nella nuova istanza e ciò avesse un impatto negativo sulla nuova istanza. Il mio pensiero era di poter verificare cosa è impostato nell’istanza corrente, creare le impostazioni pertinenti nella tabella, eseguire il backup/ripristino sulla nuova istanza e poi rimuovere gradualmente le variabili d’ambiente una alla volta.
Logico - forse no, ma ho pensato che sarebbe stato l’approccio più sensato nel caso in cui una variabile d’ambiente nell’istanza in esecuzione fosse diversa/non supportata nella nuova istanza (in esecuzione = vecchia versione di Discourse, nuova = ultima versione di Discourse).
