Von der Community unterstütztes offizielles Docker-Image

Entwickler
21

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.

22

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.

23

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.

24

Hallo zusammen!

Ich komme aus einer ziemlich großen italienischen Community, die Discourse als Forumstool nutzt. Obwohl wir Discourse lieben, haben wir einige Schwierigkeiten bei der Bereitstellung auf Kubernetes über „standardisierte

26

Hallo @Luca_Prete, hast du dir die Arbeit von @pierreozoux oben und die Antwort des Teams angesehen?

Der Großteil der Docker-Packaging-Arbeit würde darin bestehen, das nachzuahmen, was pups im Hintergrund für launcher macht, einschließlich einiger benutzerdefinierter Konfigurationen für Postgres, Sidekiq usw. @unteem hat sich eine Idee zu eigen gemacht und ist dem Weg gefolgt, den pups für frühere Versionen von Discourse beschritten hat. Die Docker-Image-Version aktuell zu halten, ist eine Herausforderung. Es wäre interessant, den gesamten Prozess zu entfalten und diesen Weg mit einem standardmäßigen Docker-Ansatz zu gehen. Wenn es einen gangbaren Weg gibt, ein Standard-Setup zu verwenden, wären viele hier meiner Meinung nach sehr erfreut.

27

@hellekin Danke.

Das habe ich noch nicht. Ich bin mir sicher, dass dort viel enthalten ist, aber ich halte mich in der Regel – zumindest bei der Arbeit – von Jobs fern, die nur einen einzelnen Benutzer unterstützen (im Gegensatz zu community-unterstützten Lösungen), einfach weil es später schwierig werden kann, sie zu warten.

Der konkrete Weg hängt stark von einigen Details der Plattform ab.

Was ich in Ihrem Fall als mögliche Lösung sehe, wäre zunächst zu verstehen, wie Standard-Images (Postgres, Redis, …) mit Discourse ohne spezifische Anpassungen funktionieren würden.
Der Grund, warum ich dies für wichtig erachte, ist, dass es Ihnen ermöglicht, überall, wo Sie Discourse installieren, auf externe, standardisierte Dienste zu vertrauen (die auf physischer Hardware, auf einer VM, in Containern, in Kubernetes als Chart-Abhängigkeiten usw. installiert sein können).
Jeder dieser Dienste bietet in der Regel die Möglichkeit, Startskripte zu verwenden, um beispielsweise eine Datenbank zu erstellen – das sollte nicht allzu schwierig sein.

Anschließend würde ich ein ordentliches Dockerfile erstellen (das automatisch auch als Quick-Start-Anleitung für Benutzer dient, die Discourse ohne Docker installieren möchten).

Dann kommt die docker-compose.yaml (diese entspricht weitgehend dem, was Bitnami auf ihrem GitHub bereitstellt).

An diesem Punkt sollten Sie in der Lage sein, Discourse auf Ihrem Laptop in Form von „Microservices

28

@unteem ist nicht allein :slight_smile: Wir arbeiten zusammen.
Wir tun dies, weil wir mehrere Discourse-Instanzen hosten.
Wir haben mit Docker begonnen und betreiben nun Kubernetes.

Wir haben unsere Arbeit unter https://lab.libreho.st/ zusammengefasst, was ein Gemeinschaftsprojekt ist (@hellekin ist ebenfalls dabei). Wir möchten unsere Arbeit in den kommenden Wochen/Monaten stärker bekannt machen.

Die Wartung ist eine echte Herausforderung… Ich habe buchstäblich Stunden, wenn nicht sogar Tage für diesen Commit verbracht, der meine Builds repariert hat:

Wie auch immer. Wir arbeiten derzeit an Kubernetes-Operatoren. Wir beginnen mit Nextcloud, dann RocketChat, und als Nächstes wird wahrscheinlich Discourse folgen.

In der Zwischenzeit finden Sie den Code für die Docker-Images, die wir verwenden, hier:

https://lab.libreho.st/libre.sh/docker/discourse-web

Die Images selbst befinden sich hier:

Wie Sie sehen, haben wir in letzter Zeit einige Zeit investiert. Wir haben also Tags und Pipelines. Wir müssen Automatisierung hinzufügen, um wöchentliche Builds zu erhalten.

Es gibt dort einen Helm-Chart:
https://git.indie.host/indiehost/helm-discourse
Aber wie Sie sehen, wird er nicht wirklich gewartet.

Was ich sagen kann, ist: Es funktioniert für uns :slight_smile: Wenn Sie mitfahren möchten und sich abenteuerlustig fühlen, fühlen Sie sich frei, uns beizutreten :slight_smile: Wir haben Spaß :slight_smile:

Wir bieten nicht wirklich Support, da wir dafür nicht viel Zeit haben, aber wenn Sie einen PR einreichen, wird er gerne angenommen. Ich wünsche mir wirklich, dass wir diese Arbeit unter dem offiziellen Discourse-Dach leisten könnten, das wäre so viel einfacher.
Aber am Ende des Tages beginne ich, das Discourse-Team zu verstehen. Sie haben nur ein Werkzeug, das sie für die Community unterstützen, und es funktioniert gut. Sie bieten guten Support für weniger technische Benutzer, und das ist wirklich nett. Wenn ein Problem auftritt, git pull && rebuild löst 99 % der Probleme :slight_smile: Ich verstehe, dass die Unterstützung eines weiteren Werkzeugs ein großes Risiko ist, und wenn es nicht unterstützt oder nicht gut gemacht wird, wird es das Projekt in gewisser Weise schädigen. Nochmals vielen Dank an das Discourse-Team für die harte Arbeit :slight_smile:
Mein einziges Problem ist, dass wir wahrscheinlich viele sind, die unsere eigene Lösung entwickeln, und der einzige Weg zur Zusammenarbeit ist, hier upstream mitzuarbeiten.

Tatsächlich wäre eine Möglichkeit, ein weiteres Image in discourse_docker zu haben, das super_base genannt wird – ohne runit/anacron/nginx/postgres – und das Basis-Image auf super_base basieren würde, sodass wir es für unsere k8s-Bereitstellung wiederverwenden könnten? Ich denke, das würde funktionieren :slight_smile:

Was halten Sie davon?

Nutzt Discourse Kubernetes? Ich bin neugierig :slight_smile:

29

@pierreozoux danke für die Antwort!

Ich finde, ihr habt großartige Arbeit geleistet, und ich würde mich gerne nach Möglichkeit einbringen :slight_smile:

Ich hatte auch mehr Zeit, mir die Arbeit der Bitnami-Mitarbeiter genauer anzusehen. Die gute Nachricht ist, dass sie die Container bereits getrennt haben. Hattet ihr schon Gelegenheit, euch das anzusehen? Was haltet ihr davon?

Hier sind die Dockerfiles, die sowohl für den Web- als auch für den Sidekiq-Container verwendet werden: bitnami/discourse Dockerfile

Ich kann den Link zur docker-compose-Datei nicht einfügen, aber ihr könnt sie ganz einfach finden, indem ihr dem Link folgt, den ich in meinem vorherigen Beitrag in diesem Thread hinzugefügt habe.

Im selben Repository gibt es auch eine Kubernetes-YAML-Datei: https://github.com/bitnami/bitnami-docker-discourse/blob/master/test.yaml

Beginnen wir mit dem Docker-Image: Seht ihr irgendwelche Probleme? Ist die Software „aktuell

30

Das ist exakt dieselbe Änderung, die von DEV: Bump uglifyjs · discourse/discourse_docker@c87937d · GitHub vorgenommen wurde. Wenn Sie das Image forken, sollten Sie prüfen, ob Sie Änderungen aus diesem Repository parallel upstreamen können.

Das ist im Wesentlichen unsere Motivation für den Status quo.

Alles hinzuzufügen, was wir intern nicht nutzen, bedeutet nur, dass es kaputtgehen und kurz darauf veraltet sein wird, was allen, die sich darauf verlassen haben, mehr Ärger bereitet. Wir hatten im Projekt mehrere Beispiele dafür.

Wenn die Community daran arbeiten möchte, ist das in Ordnung.

Nein, wir nutzen kein k8s.

31

Es ist nur so, dass es eine ganze Reihe von Abhängigkeiten gibt, die man im Auge behalten muss.

Leute posten hier ziemlich regelmäßig, dass diese auf die eine oder andere Weise nicht funktionieren.

Was ich bisher gemacht habe, ist, launcher zu verwenden, um Images zu bauen und diese in ein Repository zu pushen, das ich dann mit Kubernetes deploye. Ich habe zudem Upgrades ohne Ausfallzeit skriptet. Das ist für die Kunden, für die ich es eingerichtet habe, jedoch völlig übertrieben. Ich hoste 3 Millionen Seitenaufrufe pro Monat auf Standard-Hardware mit einer (meistens) Standard-Konfiguration (nur mit Traefik als Reverse-Proxy für mehrere Sites).

Ich habe darüber nachgedacht, eine Reihe von Images mit beispielsweise verschiedenen Plugin-Sets zu veröffentlichen, aber das Problem ist, dass bei Problemen damit hier keine Unterstützung erhalten werden kann.

32

Gibt es Änderungen zum Thema? Gibt es oder wird es ein offizielles Discourse-Image geben, das sich einfach für Kubernetes-Bereitstellungen verwenden lässt?

33

Das wird nicht passieren. Die Lösung, die ich verwende, besteht darin, das neue Image zu bootstrappen, es in ein Repository zu pushen, es dann zu starten und anschließend nach dem Hochfahren der neuen Pods Post-Upgrade-Migrationen durchzuführen.

34

Gibt es Neuigkeiten? Immer noch kein offizielles Helm Chart zur Installation von Discourse auf Kubernetes?

35

Nein, und das steht auch nicht auf unserer Roadmap.

Siehe Can Discourse ship frequent Docker images that do not need to be bootstrapped? für den Kontext.

36

Ich habe darüber nachgedacht, ein solches Angebot zu machen (und es wäre nicht „offiziell“), müsste aber sicherstellen, dass es hier keine zusätzlichen Supportprobleme verursacht und mich für die Zeit bezahlt, die ich mit der Wartung und dem Support verbringe. Ich habe wenig Ahnung, wie ich eines dieser Probleme lösen kann, aber wenn Sie ein Budget haben, können Sie mich gerne kontaktieren.

37

Wir hosten seit einigen Monaten erfolgreich Discourse auf Helm mit unserem eigenen Docker-Image.
(Zuvor haben wir ebenfalls unser eigenes Image mit Compose verwendet)

Und das mit S3/Minio-Unterstützung.

https://forge.liiib.re/indiehost/tech/infrastructure/charts/-/tree/master/discourse

(Aber es mangelt definitiv an Dokumentation und “Offenheit” für die Eröffnung von Konten und Beiträge.
Wenn es Nachfrage gibt, hier oder per PN, können wir uns öffnen :))

@pfaffman Wenn du glückliche Leute findest, die bereit sind, deine Zeit zu unterstützen, würden wir uns freuen, zusammenzuarbeiten!

Wir hosten Discourse für einige kleine Gemeinschaften, hauptsächlich in Frankreich, die Teil der Common-Bewegung sind.
(Wie https://forum.chatons.org/ ist die größte, die wir pro bono hosten)