Immagine Docker ufficiale supportata dalla community

Awesome! I’ve bookmarked this post, and if anybody asks how to run Discourse in Kubernetes or Swarm, I’ll be sure to point them at your images :+1:. Advantage of being not-an-employee: my word doesn’t have to carry the weight of being Official™.

They, on the other hand, benefit immensely from having One Official™️ Way of deploying Discourse. CDCK is not going to take on the load of maintaining a deployment system that they themselves don’t use and is massive overkill for most self-hosters. And if they don’t maintain it, they ain’t endorsing it. Brand protection demands it.

Thanks for creating this thread @pierreozoux!

I recently reached critical appreciation for discourse and got interested in hosting a deployment. I’m currently hosting JupyterHub, GitLab and Mattermost - everything through Helm charts and would very much like to do the same with Discourse.

Some background about Helm / Kubernetes:
A Helm chart is a set of configurable Kubernetes resources, and Kubernetes resources are for example a Deployment Kubernetes resource that makes a given docker image run at all time. Installing something can end up becoming a single line command + some configuration.

I would be happy to at least review code and make some PRs to fix various things in a Helm chart for discourse if it would be developed. I’m currently a maintainer of JupyterHub’s Helm chart and have various contributions to other charts.

I think it’s actually possible / feasible to break up Discourse into a set of kube pods, but have fun sizing the resource requirements for the web and sidekiq runners :slight_smile:

If insane levels of infrastructure failure tolerance is not a business requirement for you, just use the singleton fat container, it’s going to be order of magnitude cheaper & easier for the same level of steady state service.

Ciao a tutti!

Provoengo da una comunità italiana piuttosto grande che utilizza Discourse come strumento per il proprio forum.
Mentre amiamo Discourse, abbiamo anche notato alcune difficoltà nel distribuirlo su Kubernetes tramite procedure di tipo “standard”.

Capisco il dolore dei manutentori :slight_smile: Ho lavorato per anni alla Open Networking Foundation e una delle sfide più grandi è stata spostare CORD -una delle nostre piattaforme principali- dalle installazioni basate su script a Dockerfile/docker-compose e immagini Docker ospitate su DockerHub + helm-charts. Sebbene ci sia una ragionevole preoccupazione nel farlo e se una soluzione che vada bene per tutti i casi non esista davvero, posso dire che abbiamo visto i benefici fin dai primi deploy.

Di solito, il passo più importante da compiere è adottare la mentalità di lasciare che gli strumenti esistenti facciano ciò che sanno fare meglio :slight_smile: Docker ha procedure di installazione standard, semplici e già ben documentate. Gli script sono qualcosa di personalizzato, che spesso richiede adattamenti e manutenzione.
Inoltre, non c’è davvero alcun motivo per cui non si dovrebbe poter utilizzare le immagini Docker originali o gli helm-charts come dipendenze di Discourse (ad esempio unicorn, postgres, redis, …).

Consiglierei di affrontare prima le basi (ad esempio avere un Dockerfile, docker-compose e una build automatizzata su DockerHub per ogni componente). Una volta fatto questo (con le opportune modifiche al software e alla documentazione), lo sviluppo degli helm-charts è la cosa più semplice.

Sarei molto felice di aiutare, anche organizzando una chiamata insieme per discutere pro e contro delle soluzioni proposte sopra.

Durante la mia breve ricerca, ho anche notato che Bitnami (molto famosa nel mondo Docker) ha prodotto alcune immagini (https://github.com/bitnami/bitnami-docker-discourse#how-to-use-this-image). Mi chiedevo se si trattasse di un lavoro separato che hanno svolto da soli o di qualcosa di coordinato con voi. Potrebbe essere un ottimo punto di partenza. Se non ci fosse stata una partnership con loro, lo suggerirei come una possibile strada da seguire. Non sono sicuro che lo farebbero gratuitamente, ma potrebbe essere una possibilità.
Per vostra informazione, ho aperto un issue nel loro repository per saperne di più sul lavoro svolto (https://github.com/bitnami/bitnami-docker-discourse/issues/132).

Fate sapere cosa ne pensate e se posso essere d’aiuto in qualche modo.

Ciao @Luca_Prete, hai controllato il lavoro di @pierreozoux sopra e la risposta del team?

Gran parte del lavoro di packaging Docker consisterebbe nel replicare ciò che fa pups in background per launcher, inclusa una configurazione personalizzata per Postgres, Sidekiq, ecc. @unteem ha colto un’opportunità e ha seguito quanto fatto da pups per le versioni precedenti di Discourse. Mantenere l’immagine Docker aggiornata con il rilascio ufficiale è una sfida. Sarebbe interessante delineare l’intero processo e percorrere quella strada con un approccio Docker standard. Se esiste una strada percorribile verso l’uso di una configurazione standard, immagino che molte persone qui sarebbero felicissime.

@hellekin grazie.

Non l’ho fatto. Sono certo che ci sia molto da fare, ma di solito tendo a stare alla larga -almeno per il lavoro- dai progetti per singolo utente (in contrapposizione a quelli supportati dalla comunità), per il semplice motivo che potrebbero diventare difficili da mantenere in seguito.

Il percorso specifico dipende davvero da alcuni dettagli della piattaforma.

Quello che vedo come una possibile soluzione nel tuo caso sarebbe iniziare a capire come funzionerebbero le immagini standard (Postgres, Redis, …) con Discourse senza personalizzazioni specifiche.
Il motivo per cui ritengo questo aspetto importante è che ti dà la possibilità di fare affidamento -ovunque installi Discourse- su servizi esterni standard (che potrebbero essere installati su hardware fisico, su una VM, su alcuni container, su k8s sotto forma di dipendenze di chart, …).
Ognuno di questi servizi tipicamente consente l’uso di alcuni script di avvio, per creare un database e così via… non dovrebbe essere così difficile.

Poi creerei un Dockerfile appropriato (che diventa automaticamente anche la tua guida di avvio rapido per gli utenti che desiderano installare Discourse senza Docker).

Successivamente arriverebbe il docker-compose.yaml (questo è praticamente lo stesso di ciò che Bitnami espone sul loro GitHub)

A questo punto dovresti essere in grado di avviare Discourse sul tuo laptop sotto forma di "micro"servizi, utilizzando immagini di dipendenze standard, in pochi secondi, con un solo comando, senza alcuno script personalizzato.

Infine, ma non meno importante, arriva il divertimento con Kubernetes (pochi file yaml, eventualmente impacchettati sotto forma di helm-charts), da pubblicare sul repository ufficiale e stabile, o in alternativa -almeno all’inizio del processo- sul tuo repository self-hosted.

@unteem non è solo :slight_smile: Lavoriamo insieme.
Facciamo questo perché ospitiamo diverse istanze di Discourse.
Abbiamo iniziato con Docker e ora operiamo su Kubernetes.

Abbiamo spostato il nostro lavoro su https://lab.libreho.st/, che è uno sforzo comunitario (anche @hellekin ne fa parte). Nei prossimi settimane/mesi vogliamo dare più visibilità al nostro lavoro.

È una vera seccatura mantenerlo… Ho letteralmente passato ore, se non giorni, per questo commit che ha risolto i miei build:

Comunque, stiamo lavorando su operatori Kubernetes. Iniziamo con Nextcloud, poi RocketChat, e il prossimo sarà probabilmente Discourse.

Nel frattempo, puoi trovare il codice per le immagini Docker che usiamo qui:

Le immagini stesse si trovano qui:

Come puoi vedere, ci abbiamo dedicato tempo ultimamente, quindi abbiamo tag e pipeline. Dobbiamo aggiungere automazione per avere build settimanali.

Abbiamo anche una chart Helm qui:
https://git.indie.host/indiehost/helm-discourse
Ma come puoi vedere, non è davvero mantenuta.

Posso dire che per noi funziona :slight_smile: Se vuoi condividere il viaggio e ti senti avventuroso, sentiti libero di unirti a noi :slight_smile: Ci divertiamo :slight_smile:

Non offriamo davvero supporto, non abbiamo molto tempo per farlo, ma se fai una PR, sarà benvenuta. Vorrei davvero che potessimo fare questo lavoro sotto l’ombrello ufficiale di Discourse, sarebbe molto più semplice.
Ma alla fine della giornata, inizio a capire il team di Discourse. Hanno solo uno strumento che supportano per la comunità, e funziona bene. Offrono un buon supporto per utenti non troppo tecnici, e questo è davvero bello. Se c’è un problema, git pull && rebuild risolve il 99% dei problemi :slight_smile: Capisco che supportare un altro strumento sia un grosso rischio, e se non supportato o non fatto bene, potrebbe danneggiare il progetto in qualche modo. Ancora, grazie mille al team di Discourse per il duro lavoro :slight_smile:
Il mio unico problema è che probabilmente siamo molti a sviluppare la nostra soluzione, e l’unico modo per collaborare è farlo qui a monte.

In realtà, un modo per farlo sarebbe avere un’altra immagine in discourse_docker chiamata super_base? senza runit/anacron/nginx/postgres, e la base sarebbe basata su super_base, così potremmo riutilizzarla per il nostro deployment su k8s? Penso che funzionerebbe :slight_smile:

Cosa ne pensi?

Discourse usa Kubernetes? Sono curioso :slight_smile:

@pierreozoux grazie per la risposta!

Penso che abbiate fatto un ottimo lavoro e sarei felice di contribuire nel possibile :slight_smile:

Ho anche avuto più tempo per esaminare meglio il lavoro svolto dal team di Bitnami. La buona notizia è che hanno già separato i container. Avete avuto modo di darci un’occhiata? Cosa ne pensate?

Ecco i file Docker utilizzati sia per i container web che per sidekiq: bitnami/discourse Dockerfile

Non posso incollare il link al docker-compose, ma potete trovarlo facilmente seguendo il link che ho aggiunto nel mio post precedente nella discussione.

Nello stesso repository c’è anche un file YAML per Kubernetes: https://github.com/bitnami/bitnami-docker-discourse/blob/master/test.yaml

Partendo dall’immagine Docker, notate qualche problema? Il software è abbastanza “aggiornato”?

Ciò che sembra mancare è l’helm-chart, che dovrebbe essere realizzato seguendo le best practice adottate per le chart stabili.

Cosa ne pensate? Potrebbe valere la pena unire gli sforzi e integrare i vostri file nel loro lavoro?

È esattamente lo stesso cambiamento apportato da DEV: Bump uglifyjs · discourse/discourse_docker@c87937d · GitHub. Se stai facendo un fork dell’immagine, potresti voler considerare di integrare le modifiche da quel repository in parallelo.

Questo è praticamente il motivo per cui manteniamo lo status quo.

Aggiungere qualsiasi cosa che non usiamo internamente significa solo che si romperà e verrà deprecata poco dopo, causando ulteriori problemi a tutti quelli che ne dipendevano. Abbiamo avuto diversi esempi di questo nel progetto.

Se è qualcosa che la comunità vuole realizzare, va bene.

No, non usiamo k8s.

È solo che ci sono un sacco di dipendenze da tenere aggiornate.

Le persone pubblicano abbastanza regolarmente qui che non funzionano in un modo o nell’altro.

Quello che ho fatto è usare launcher per costruire le immagini e spingerle in un repository che poi distribuisco con Kubernetes; ho anche scriptato aggiornamenti a zero downtime. È un eccesso enorme per i clienti per cui l’ho configurato. Sto ospitando 3 milioni di visualizzazioni di pagine al mese su hardware commodity con una configurazione (per lo più) standard (ha solo traefik che fa reverse-proxy per più siti).

Ho considerato la possibilità di pubblicare un set di immagini con, ad esempio, diversi set di plugin, ma il problema è che se ci sono problemi, non possono ottenere supporto qui.

Ci sono aggiornamenti sull’argomento? Esiste, o sarà disponibile, un’immagine ufficiale di Discourse che possa essere utilizzata facilmente per i deployment su Kubernetes?

Non ci sarà. La soluzione che uso è avviare l’immagine nuova, caricarla in un repository, poi avvviarla e infine eseguire le migrazioni post-aggiornamento dopo che i nuovi pod sono stati avviati.

Ci sono aggiornamenti? Ancora nessun Helm Chart ufficiale per installare Discourse su Kubernetes?

No, e non è nemmeno nella nostra roadmap.

Vedi Can Discourse ship frequent Docker images that do not need to be bootstrapped? per il contesto.

Ho preso in considerazione la possibilità di fare un’offerta del genere (e non sarebbe “ufficiale”), ma avrei bisogno di assicurarmi che non creasse ulteriori problemi di supporto qui e mi pagasse per il tempo che ho dedicato a mantenerla e supportarla. Ho poca idea di come risolvere entrambi questi problemi, ma se hai un budget, non esitare a contattarmi.

Stiamo ospitando con successo discourse su Helm con la nostra immagine Docker da alcuni mesi.\n(prima usavamo anche la nostra immagine, con compose)\n\nE questo con supporto S3/Minio.\n\nhttps://forge.liiib.re/indiehost/tech/infrastructure/charts/-/tree/master/discourse\nhttps://lab.libreho.st/libre.sh/docker/discourse/\n\n(ma manca decisamente documentazione e “apertura” per aprire account e contribuire.\nSe c’è richiesta, qui o in PM, possiamo aprire :))\n\n@pfaffman se trovi persone felici disposte a supportare il tuo tempo, saremmo felici di collaborare!\n\nStiamo ospitando discourse per alcune piccole comunità, principalmente in Francia, parte del movimento comune.\n(Come https://forum.chatons.org/ è il più grande che ospitiamo pro bono)