Oh man that’s tragic. So sorry to hear 
Discourse può distribuire frequentemente immagini Docker che non necessitano di essere bootstrapate?
7 Mi Piace
https://meta.discourse.org/t/official-cloud-native-docker-image-from-discourse/228568/8
@sam e questo argomento chiariscono che questo non verrà mai risolto, anche se bitnami l’ha appena fatto…
Almeno abbiamo avuto una risposta alla nostra domanda, che è no.
Che ne dici di evitare di usare root in primo luogo? Usare fakeroot dimostra che il principale ostacolo sono i percorsi codificati (come /var). Altrimenti, ad eccezione dei vari bug e problemi che l’attuale configurazione presenta, potrebbe funzionare.
È un peccato vedere un software così valido avere una procedura di configurazione obbligatoria così mal progettata, basata su un’errata interpretazione della containerizzazione. È chiaro che è stato fatto con le migliori intenzioni; tuttavia, il risultato è qualcosa che non può essere distribuito al di fuori di un ambiente hobbistico.
1 Mi Piace
La nostra immagine viene eseguita come utente di discourse, e penso che anche quella ufficiale.
Comunque, è fantastico che il mondo “aziendale” sia interessato, perché ha molto più tempo/denaro di quello hobbistico 
Sono sicuro che la community apprezzerà il tuo contributo per migliorare l’ecosistema!
1 Mi Piace
Questo non è certamente corretto, distribuiamo la nostra immagine usando nomad su flotte di macchine, ci sono oltre 10000 container discourse in esecuzione su aws e metal in questo preciso momento
3 Mi Piace
Gli strumenti richiedono i privilegi di root per essere eseguiti e necessitano di accesso alla directory /var dell’host.
Collaboro spesso con community e aziende open source per migliorare la loro configurazione dei container. Sarei lieto di aiutare e/o considerare finanziamenti per avere una configurazione containerizzata più ragionevole.
Non è obbligatorio. È solo che se hai bisogno di una guida per configurarlo, questo è il modo per farlo. Ho aiutato clienti che utilizzano gke, eks, ecs, per esempio. Sei il benvenuto a contattarmi se hai bisogno di aiuto con i tuoi requisiti particolari.
/var non è codificato in modo fisso; ho lavorato di recente con qualcuno che lo aveva in /var/www/discourse (il che sembrava una pessima idea, poiché corre il rischio di servire dati segreti al web, ma era una “policy”).
Non è mal progettato, è mal progettato se dovessi progettarlo oggi piuttosto che un decennio fa. All’epoca era un buon progetto, e funziona ancora per gestire la loro infrastruttura e anche per molte persone che non sanno nulla di amministrazione di sistema.
2 Mi Piace
Presumo che tu non ti stia affidando agli strumenti ufficiali come discourse-setup, che richiede i privilegi di root per essere eseguito e che è probabilmente pensato per un’installazione locale.
Dai un’occhiata al codice sorgente di discourse-setup. Se hai familiarità con la configurazione e l’ottimizzazione delle prestazioni di Discourse, allora non è obbligatorio.
Launcher fa tutto il lavoro pesante per costruire l’immagine dallo yml risultante.
2 Mi Piace
Tutto può essere fatto, ma mi sembra uno sforzo inutile.
- Usa
fakerootprima di ogni comando /varpuò essere modificato modificando il file yaml:sed -i \"s;host: /var/discourse;host: $PWD/discourse;g\" containers/*.yml--skip-connection-test(trovato guardando il codice, perché lo script non è in grado di verificare la connessione se c’è un proxy inverso)- Vedo qualcosa relativo a certbot che so già che dovrò capire come disabilitare poiché il SSL offloading viene solitamente fatto esternamente
- Le porte di
containers/app.ymlpossono essere modificate in modo da utilizzare porte>= 1024, ma non sembra essere sufficiente:Error starting userland proxy: error while calling PortManager.AddPort(): cannot expose privileged port 443
Non voglio essere scortese, ma avere più servizi in esecuzione in un singolo container è sempre stato un cattivo design, poiché significa avere poco o nessun modo di sapere cosa sta succedendo ai singoli servizi, dover impostare un meccanismo personalizzato di analisi dei log al di fuori di Docker, nessun healthcheck utile, non poter fare affidamento facilmente su un database esterno, ecc. Può essere fatto se è l’unico servizio che gestisci nella tua attività, ma se ogni altro servizio inizia a farlo, la maggior parte dei vantaggi dell’utilizzo dei container svanisce.
Sarei felice di inviare alcune PR e documentazione per far funzionare Discourse in un ambiente compatibile con Docker senza accesso root, ma separare i servizi e avere una configurazione standard sarebbe un’impresa ardua senza la garanzia che verrebbe integrata.
Se non sei d’accordo con aspetti fondamentali di come è costruito Discourse, hai considerato l’utilizzo di un prodotto diverso?
3 Mi Piace
Ok, capisco meglio.
Discourse ha una forte opinione sugli strumenti per l’auto-hosting. Permette loro di fornire un supporto efficiente alla maggior parte degli amministratori non così esperti che vogliono distribuire Discourse. Puoi essere d’accordo o meno, anch’io ero un po’ triste in passato, ma ora capisco meglio 
Se hai un’esigenza diversa da una rapida messa in funzione come la maggior parte delle persone, allora sei per lo più da solo. Una volta che lo sai, va bene
Abbiamo la stessa esigenza di un’immagine Docker Discourse standalone. La eseguiamo su Kubernetes con Minio, è stato un po’ un problema per farla funzionare, ed è ancora un grande sforzo. Abbiamo ricevuto un valido aiuto da Discourse per farlo.
Il nostro lavoro è disponibile qui:
https://forge.liiib.re/indiehost/tech/infrastructure/charts/-/tree/master/discourse
(non è abbastanza documentato, né testato, né mantenuto o aggiornato in tempo, né automatizzato, ed è probabilmente un po’ personalizzato, è quello che è)
Se le persone sono interessate a migliorarlo, non esitate a venire e fare una PR, o a chattare qui: https://matrix.to/#/#libresh:liiib.re
Ma sì, il team di Discourse ha una forte opinione sulla versione comunitaria di Discourse. Puoi essere d’accordo o meno, ma forniscono la maggior parte del supporto alle persone, e per quanto poco ho visto, è un supporto straordinario, quindi penso che sia stata una buona decisione
6 Mi Piace
Questi sono aspetti fondamentali di come Discourse è impacchettato, più che di Discourse stesso, che è un ottimo software, ma hai ragione, dovrei considerare soluzioni diverse.
2 Mi Piace
Sentite libero di rimuovere i template per postgres e redis (così come ssl e let’s encrypt) e di usare i vostri.
2 Mi Piace
Grazie per aver condiviso. Ho anche trovato GitHub - literatecomputing/docker-compose-discourse: Launch Discourse with docker-compose and similar e immagini da bitnami. Il problema principale è che queste soluzioni non sono ufficialmente supportate. Mi chiedo se potrebbe essere un’idea avere una configurazione Docker alternativa supportata dalla community, invece di avere vari repository personalizzati, poiché non sarebbe efficiente distribuire lo sforzo in più luoghi.
1 Mi Piace
Hai ragione, le impostazioni possono essere modificate in effetti. Se riesco a farlo funzionare senza grandi sforzi, proverò a inviare alcune PR per migliorare gli strumenti o la documentazione esistenti, come ad esempio eseguirlo senza privilegi di root. Ciò dovrebbe essere compatibile con le opinioni del team di sviluppo, portando nel contempo un po’ di sollievo ad alcuni amministratori di sistema più esigenti.
9 anni dopo, sembra che Docker idiomatico sia coperto da Discourse di Bitnami?
Ma altrove in questo forum ci sono affermazioni secondo cui consuma molta RAM e non è supportato. Sono rimasto sorpreso nel vedere quanta difficoltà ci sia ancora nella configurazione canonica quando si cerca di farlo funzionare nel cloud.
Molti servizi di questi giorni come Redis, PostgreSQL e storage compatibile con S3 sono facili da configurare e spostare tra diversi host come DigitalOcean, Supabase, AWS, ecc., quindi il backend è portatile. La VM che esegue Discourse sembra che dovrebbe essere altrettanto facile da scalare/sostituire con build deterministiche. È un peccato che sia così vicino a questo ideale ma frenato.
Come ha detto un altro utente, questo è sorprendente:
La logica a cui si alludeva in precedenza nel thread, secondo cui rendere questo più facile potrebbe ostacolare le opportunità commerciali, è strana. Gli interessi commerciali avranno personale per gestire le build complesse, quindi questo colpisce più i singoli sviluppatori che chiunque altro. Il mio caso d’uso personale è che gestisco una community molto grande (senza scopo di lucro). Quindi non rientra nell’hobbistica per scala o commerciale per entrate.
1 Mi Piace
Eh… sto pensando di creare un forum/bacheca comunitaria e ovviamente ho pensato di usare Discourse (perché apprezzo l’esperienza utente) ma ancora una volta mi sono scontrato con il blocco dell’installazione/gestione completamente ostile…
Nel corso degli anni mi sono affezionato moltissimo ad avere tutto gestito con un semplice file docker-compose, aggiungendo un paio di elementi aggiuntivi (database, minio per storage compatibile con s3 e quant’altro) ma niente da fare… Discourse è ancora super ostile in questo caso.
Mi dispiace, ma avere un qualche stupido “launcher” per avviare le cose?
E poi il processo di aggiornamento che afferma:
> Crea manualmente una nuova immagine di base eseguendo: ./launcher rebuild my_image``
scusa, ricostruire manualmente l’immagine? Ma che cavolo… è come avere/usare docker ma in realtà non usarlo…
Funziona ./launcher rebuild app? È il comando usuale.
Inoltre, hai seguito la guida di installazione standard?
Non ho nulla di costruttivo da commentare, quindi vi chiedo di provare ad aggiornare il server Mastodon, Pixelfed, Moodle… Discourse è incredibilmente facile.
Un comando manuale è un ostacolo 
2 Mi Piace