Ciao!\n\nAbbiamo creato un repository chiamato RPS Discourse Image Builder che viene utilizzato per creare un’immagine OCI di Discourse. Penso che questo possa essere utile ad alcune persone che cercano qui. L’abbiamo fatto principalmente in modo da non dover aspettare il deploy di Discourse, che richiede molto tempo, e per poter bloccare in modo affidabile le versioni di Discourse.\n\nAbbiamo scritto uno script che utilizza il repository discourse_docker per creare l’immagine con la versione stabile nel modo più generale possibile.\n\nEsiste anche un file docker compose che avvia i database necessari per la creazione e l’immagine di Discourse per il testing ed esegue il tutto per lo sviluppo locale. Questo può essere eseguito su un GitLab runner con l’executor shell, ma è necessario un sistema con una versione di docker-compose che supporti i profili.\n\n## Approccio\n\nLo script di build dovrebbe essere eseguito all’interno delle nostre pipeline CI/CD in modo da poter aggiornare facilmente la versione, in modo che ulteriori aggiustamenti vengano eseguiti in repository diversi con Dockerfile basati sull’immagine creata da questo repository.\n\n## Contesto\n\nDiscourse è un software molto valido, ma non è molto facile da deployare e da bloccare per versione. Questo repository viene utilizzato per creare un’immagine docker che può essere utilizzata per deployare Discourse.\n\nIl problema è che Discourse ha un modo molto particolare di costruire le proprie immagini docker. Gli sviluppatori di Discourse si aspettano che tu costruisca l’immagine sulla macchina di destinazione con il loro repository discourse_docker.\n\nCi sono state lunghe discussioni su questo argomento nel forum, TL;DR: gli sviluppatori principali di Discourse rifiutano di supportare un’immagine docker pubblica che possa essere utilizzata per deployare Discourse. Vogliono mantenere il repository discourse_docker come unico modo ufficiale per deployare Discourse.\n\nGli svantaggi principali di questo approccio sono:\n\n* Non è possibile, secondo la nostra esperienza, bloccare in modo affidabile le versioni di Discourse.\n* Richiede molto tempo per costruire l’immagine e, una volta costruita, il servizio non è disponibile. Inoltre, Discourse ha il ciclo di iterazione DevOps più lungo di tutti i servizi che supportiamo.\n* I database sono gestiti in modo diverso rispetto ai normali progetti basati su docker.\n* La storia di deploy ufficiale di Discourse è incompatibile con i flussi di lavoro di sviluppo e i deploy basati su OCI, come Kubernetes o anche Docker-Compose.\n* Il launcher discourse_docker fa molte supposizioni sull’ambiente in cui viene eseguito. Ad esempio, rifiuta di essere eseguito su Podman senza root con un errore relativo a volumi di storage mancanti, senza poter aggirare questo problema con un argomento o una variabile d’ambiente.
Esiste un parametro version nel file app.yml che può essere impostato sulla versione che si desidera eseguire.
Utilizzando l’installazione ufficiale gestita tramite Spostamento da container standalone a container web e dati separati.
Vero, cerchiamo di renderlo facile per i webmaster con il metodo “trascina e rilascia il contenuto di questo file zip con FileZilla tramite FTP”, garantendo al contempo che tutti eseguano versioni recenti, supportate e patchate di tutto il software nello stack, anche dei loro database.
Per gli amministratori di Discourse più esperti, è possibile puntare a un database gestito esternamente tramite una variabile d’ambiente, come descritto in Configurare Discourse per utilizzare un server PostgreSQL separato.
Sì, il flusso basato sul launcher non è compatibile “out-of-the-box” con l’orchestrazione dei container. Detto questo, può essere reso compatibile eseguendo ./launcher bootstrap app, inserendo l’immagine risultante in un registro di container e quindi eseguendo tale immagine tramite orchestrazione.
Accogliamo con favore una pull request per rendere ciò possibile, poiché sembra essere utile in generale. pr-welcome
Abbiamo provato a farlo per creare un deployment da 2.8, ma fallisce lamentandosi di una versione errata di Discourse. Poiché ora possiamo riprodurlo nel nostro CI/CD, puoi vedere l’errore qui: docker-build (#4121616927) · Jobs · idcohorts / RPS / Discourse Image Builder · GitLab
È fondamentalmente quello che stiamo facendo. 
Grazie, ci sto lavorando.
Questo perché Discourse 2.8 non è più supportato, il che significa che non abbiamo eseguito il backporting dell’ultima versione di Ruby, e funziona con una versione di Ruby che è già EOL. Nessuno dovrebbe eseguirlo in produzione.
Tuttavia, non è nemmeno tecnicamente possibile (cambiando solo il parametro della versione), quindi non possiamo più riprodurre vecchi ambienti.
beh, puoi farlo, devi solo usare un’immagine di base più vecchia.
Come posso farlo? L’ho cercato e non ho trovato una soluzione…
Fai riferimento letteralmente all’immagine di base precedente (creata approssimativamente intorno alla data della release a cui ti stai rivolgendo - ovviamente deve essere successiva)
Ci sono pagine (e pagine!) di esse:
Ma se si tenta di bloccare una versione troppo vecchia, potrebbe non funzionare con le versioni aggiornate dell’immagine di base di Discourse. Non ricordo esempi specifici, ma cose come una vecchia versione di Discourse non funzioneranno con Ruby 3.2, quindi è anche necessario (a volte) bloccare discourse_docker se si blocca una vecchia versione di Discourse.
La soluzione più sicura e, nella maggior parte dei casi, meno dispendiosa è quella di creare un’immagine e caricarla in un repository piuttosto che creare una nuova immagine ad ogni distribuzione. E se si hanno plugin, è probabile che sia necessario bloccare anche ciascuno di essi.
L’ho fatto per diversi clienti per ECS e k8s su GCP e AWS.
Sono abbastanza sicuro che tu possa farlo se blocchi anche discourse_docker alla vecchia versione. Come ho menzionato sopra, è più complicato con i plugin, poiché è probabile che sia necessario bloccare anche quelli alle vecchie versioni. Se vuoi davvero mantenere vecchie versioni, crearle esattamente una volta e caricarle in un repository è la strada da percorrere. Lo sto facendo con un cliente per testare i percorsi di aggiornamento dalla produzione attuale all’ultima versione e sta funzionando senza intoppi.