Questa era una nota sul motivo per cui il campione di composizione che ho pubblicato non utilizzava l’immagine PG generica.
Discourse può distribuire frequentemente immagini Docker che non necessitano di essere bootstrapate?
Hmm… ma non diresti che questo rende altri modi più complessi?
Capito! 
Come guru di Docker, tutto questo dovrebbe esserti molto facile?
3 Mi Piace
Come sto cercando di spiegare da un paio di giorni, con la soluzione attualmente fornita tutto tranne che facile 
in breve;
Una semplice immagine di Discourse (simile a quella di Bitnami) con un sacco di variabili d’ambiente per configurare cose basilari (come l’accesso a Redis, al database) sarebbe più che sufficiente, ma per qualche motivo questo è un completo divieto… 
Sto condividendo qui delle prove di concetto per fare esattamente questo.
Per un plugin semplice certo, ma non possiamo dare per scontato che un plugin avrà un certo aspetto: alcuni plugin necessitano di configurazioni aggiuntive, gem aggiuntive da installare, o dipendenze di gem aggiuntive o programmi esterni che richiedono un apt-get install. Questo dovrebbe essere integrato in un’immagine personalizzata.
Sarebbe fantastico vederlo realizzato, ma non è banale.
Riguardo all’aggiornamento web, gli operatori di Discourse non dovrebbero nemmeno conoscere la CLI o docker.
1 Mi Piace
Devi solo creare la tua immagine con il launcher (cosa che puoi fare con GitHub Actions), caricarla in un repository e avviarla con le variabili d’ambiente. Devi comunque migrare il database, precompilare gli asset e caricarli su S3. Puoi migrare il database e usare skip_post_deployment_migrations in modo che il vecchio container possa continuare a funzionare finché quello nuovo non è operativo, e poi spegnerlo ed eseguire il resto delle migrazioni. Ma è decisamente troppo complicato per qualcuno che non conosce Discourse molto più di quanto pensi che tu voglia sapere. E ci sono molte, molte cose che possono andare storte, motivo per cui la soluzione attuale, che è orribile per tutte le ragioni che hai delineato, è la soluzione migliore per migliaia di persone che non sanno cos’è bash.
Per la maggior parte, devi solo eseguire ./launcher rebuild app, tranne una volta ogni paio d’anni quando devi aggiornare il database, quindi devi farlo due volte. Non puoi ottenere quel livello di semplicità con docker-compose. C’è la possibilità che se docker-compose fosse stato utilizzabile quando hanno iniziato, avrebbero potuto usarlo invece di dover creare il proprio, ma le cose non sono andate così.
Se vuoi usare l’immagine Bitnami, puoi farlo, ma non puoi ricevere molto aiuto qui. Scommetto che funziona anche per molte persone.
1 Mi Piace
hmm… per un linguaggio/ambiente che dovrebbe essere universale e indipendente dalla piattaforma, fare affidamento sul gestore di pacchetti del sistema operativo sottostante sembra piuttosto strano… 
Questo è ciò a cui ci si riferiva in precedenza, ovvero che Discourse sembra essere saldamente ancorato al “vecchio” modo di gestire software/forum PHP
Quindi, per riassumere l’intera discussione (e magari metterlo nel primo messaggio per evitare di ripeterlo all’infinito ):
- Discourse è su misura e focalizzato su “persone normali” e l’intera configurazione è orientata a soddisfare le loro esigenze
- Dato quanto Ruby (ambiente) sia un po’ strano e (1) sia praticamente impossibile fornire immagini docker ufficiali sufficientemente generiche nel repository ufficiale di Discourse
corretto?
Direi in modo leggermente diverso
Dato che non esiste un’immagine ufficiale (di default) che offra un modo diverso per configurare Discourse rispetto al launcher, il che rende il launcher il modo predefinito e fondamentalmente unico (raccomandato) per configurare Discourse, si potrebbe sostenere che l’affermazione originale sia ancora valida
Ma queste sono solo questioni semantiche.
In ogni caso, l’argomento è:
Discourse può fornire immagini Docker frequenti che non necessitano di essere avviate
Da tutta la discussione sembra che: “No, Discourse non può/non vuole fornire immagini Docker frequenti che non necessitano di essere avviate”, q.e.d.
Quindi il suggerimento di aggiungere un commento proprio all’inizio, che tale immagine non verrà fornita, farebbe risparmiare MOLTO fastidio
Questa è un’ipotesi errata
Non abbiamo ancora dato priorità alla distribuzione di un’immagine ufficiale con un pacchetto di plugin specifici
È un lavoro che stiamo considerando, abbiamo molte idee su come farlo, semplicemente non è stata una priorità aziendale
5 Mi Piace
traduzione da una persona che lavora su un altro progetto: “potrebbe succedere in futuro, ma potrebbe anche non succedere… dato che non è una priorità / non è in una roadmap le possibilità che accada sono minime o nulle”
Comunque, più seriamente, una configurazione di base con un insieme sensato di plugin inclusi sarebbe fantastica!
Grazie per il contributo! <3
A titolo informativo, ho impostato un modo per creare un’immagine Discourse su una devbox e distribuirla su un server in modo da eliminare la necessità di utilizzare lo script launcher.
Maggiori discussioni a riguardo qui in una pull request che ho creato.
Ho impostato questo in modo che sia completamente compatibile con la configurazione Docker ufficiale di Discourse, quindi non dovrai preoccuparti che questa soluzione diventi obsoleta o si interrompa.
Il TLDR su come funziona è che ho reso l’immagine Docker responsabile dell’esecuzione dei comandi di bootstrap all’avvio (invece dello script launcher).
1 Mi Piace
Bel approccio.
Inoltre: interessante launcher v2 (GitHub - discourse/launcher: Discourse Launcher CLI)!
2 Mi Piace