Discourse Image Builder für Gitlab CI/CD Pipelines

[mkbrechtel (Markus Katharina Brechtel)]

Hallo!

Wir haben ein Repository namens RPS Discourse Image Builder erstellt, das zum Erstellen eines Discourse OCI-Images verwendet wird. Ich denke, das könnte für einige Leute, die hier suchen, hilfreich sein. Wir haben dies hauptsächlich getan, damit wir nicht auf das langwierige Discourse-Deployment warten müssen und um Discourse-Versionen zuverlässig festlegen zu können.

Wir haben ein Skript geschrieben, das das discourse_docker Repo verwendet, um das Image auf die stabilste und allgemeinste Weise zu erstellen.

Es gibt auch eine Docker-Compose-Datei, die die für den Build erforderlichen Datenbanken und das Discourse-Image zum Testen hochfährt und für die lokale Entwicklung ausführt. Dies kann auf einem GitLab-Runner mit dem shell-Executor ausgeführt werden, erfordert jedoch ein System mit einer docker-compose-Version, die Profile unterstützt.

Ansatz

Das Build-Skript sollte innerhalb unserer CI/CD-Pipelines ausgeführt werden, damit wir die Version einfach aktualisieren können. Weitere Anpassungen erfolgen in verschiedenen Repositories mit Dockerfiles, die auf dem von diesem Repository erstellten Image basieren.

Hintergrund

Discourse ist eine sehr gute Software, aber nicht sehr einfach bereitzustellen und Versionen festzulegen. Dieses Repository wird verwendet, um ein Docker-Image zu erstellen, das zur Bereitstellung von Discourse verwendet werden kann.

Das Problem ist, dass Discourse eine sehr einzigartige Methode zum Erstellen seiner Docker-Images hat. Die Discourse-Entwickler erwarten, dass Sie das Image auf der Zielmaschine mit ihrem discourse_docker-Repo erstellen.

Es gab dazu ausführliche Diskussionen im Forum, TL;DR: Die führenden Discourse-Entwickler weigern sich, ein öffentliches Docker-Image zu unterstützen, das zur Bereitstellung von Discourse verwendet werden kann. Sie möchten das discourse_docker-Repo als einzigen offiziellen Weg zur Bereitstellung von Discourse beibehalten.

Die Hauptnachteile dieses Ansatzes sind:

• Nach unserer Erfahrung ist es nicht möglich, Discourse-Versionen zuverlässig festzulegen.
• Es dauert lange, das Image zu erstellen, und wenn das Image erstellt ist, ist der Dienst nicht verfügbar. Außerdem hat Discourse den längsten DevOps-Iterationszyklus aller von uns unterstützten Dienste.
• Datenbanken werden anders verwaltet als bei üblichen Docker-basierten Projekten.
• Die offizielle Discourse-Bereitstellungsstrategie ist mit OCI-basierten Entwicklungs- und Bereitstellungsworkflows wie Kubernetes oder sogar Docker-Compose unvereinbar.
• Der offizielle Discourse-Launcher trifft viele Annahmen über die Umgebung, in der er ausgeführt wird. Zum Beispiel weigert er sich, auf rootless Podman mit einer Fehlermeldung über fehlende Speicher-Volumes zu laufen, ohne dies mit einem Argument oder einer Umgebungsvariable umgehen zu können.

[Falco]

@mkbrechtel

Es ist nach unserer Erfahrung nicht möglich, Discourse zuverlässig nach Version zu sperren.

Es gibt einen version-Parameter in der Datei app.yml, der auf die gewünschte Version gesetzt werden kann.

@mkbrechtel

Das Erstellen des Images dauert lange und wenn das Image erstellt ist, ist der Dienst nicht verfügbar. Außerdem hat Discourse den längsten DevOps-Iterationszyklus aller von uns unterstützten Dienste.

Verwenden Sie die offizielle Installation, die über Umzug vom Standalone-Container zu separaten Web- und Datencontainern gehandhabt wird.

@mkbrechtel

Datenbanken werden anders verwaltet als bei üblichen Docker-basierten Projekten.

Das stimmt, wir versuchen, es für Webmaster freundlich zu gestalten, indem sie “diesen Zip-Dateieninhalt mit FileZilla über FTP ziehen und ablegen”, während wir sicherstellen, dass alle die aktuellen, unterstützten und gepatchten Versionen aller Software im Stack ausführen, einschließlich ihrer Datenbanken.

Für erfahrenere Discourse-Administratoren ist die Angabe einer extern verwalteten Datenbank nur eine Umgebungsvariable entfernt, wie unter Discourse für die Verwendung eines separaten PostgreSQL-Servers konfigurieren beschrieben.

@mkbrechtel

Die offizielle Discourse-Deployment-Story ist mit OCI-basierten Entwicklungs- und Deployment-Workflows wie Kubernetes oder sogar Docker-Compose unvereinbar.

Ja, der Launcher-basierte Ablauf ist nicht Out-of-the-Box mit Container-Orchestrierung kompatibel. Das gesagt, es kann kompatibel gemacht werden, indem ./launcher bootstrap app ausgeführt und das resultierende Image in eine Container-Registry gepusht und dann dieses Image über Orchestrierung ausgeführt wird.

@mkbrechtel

Zum Beispiel weigert es sich, auf Rootless Podman mit einer Fehlermeldung über fehlende Speicher-Volumes zu laufen, ohne dass dies mit einem Argument oder einer Umgebungsvariable umgangen werden kann.

Wir freuen uns über einen Pull-Request, um dies zu ermöglichen, da es generell nützlich zu sein scheint. pr-welcome

[mkbrechtel (Markus Katharina Brechtel)]

@Falco

Es gibt einen version-Parameter in der Datei app.yml, der auf die gewünschte Version gesetzt werden kann.

Wir haben das versucht, um ein Deployment von 2.8 zu erstellen, aber es schlägt mit der Beschwerde einer falschen Discourse-Version fehl. Da wir dies jetzt in unserem CI/CD reproduzieren können, können Sie den Fehler hier einsehen: docker-build (#4121616927) · Jobs · idcohorts / RPS / Discourse Image Builder · GitLab

@Falco

Verwendung der offiziellen Installation, die mit Move von einem Standalone-Container in separate Web- und Datencontainer behandelt wird.

@Falco

Ja, der Launcher-basierte Flow ist nicht sofort mit Container-Orchestrierung kompatibel. Das heißt, er kann kompatibel gemacht werden, indem ./launcher bootstrap app ausgeführt und das resultierende Image in eine Container-Registry gepusht und dann dieses Image über Orchestrierung ausgeführt wird.

Das ist im Grunde das, was wir tun.

@Falco

Wir freuen uns über einen Pull-Request, um dies zu ermöglichen, da es generell nützlich erscheint. pr-welcome

Danke, ich kümmere mich darum.

[Falco]

@mkbrechtel

Wir haben versucht, ein Deployment von 2.8 zu erstellen, aber es schlägt mit der Beschwerde über eine falsche Discourse-Version fehl. Da wir dies jetzt in unserer CI/CD reproduzieren können, können Sie den Fehler hier einsehen: docker-build (#4121616927) · Jobs · idcohorts / RPS / Discourse Image Builder · GitLab

Das liegt daran, dass Discourse 2.8 jetzt nicht mehr unterstützt wird, was bedeutet, dass wir die neueste Ruby-Version nicht zurückportiert haben und sie auf einer Ruby-Version läuft, die bereits EOL ist. Niemand sollte sie in der Produktion betreiben.

[mkbrechtel (Markus Katharina Brechtel)]

@mkbrechtel

Danke, bin dran.

Erledigt, siehe add bypasses for unsupported docker versions by mkbrechtel · Pull Request #706 · discourse/discourse_docker · GitHub

[mkbrechtel (Markus Katharina Brechtel)]

@Falco

Das liegt daran, dass Discourse 2.8 jetzt nicht mehr unterstützt wird, was bedeutet, dass wir die neueste Ruby-Version nicht zurückportiert haben und es auf einer Ruby-Version läuft, die bereits EOL ist. Niemand sollte es in der Produktion betreiben.

Dennoch ist es nicht einmal technisch möglich (nur durch Ändern des Versionsparameters), sodass wir alte Umgebungen nicht mehr reproduzieren können.

[merefield (Robert)]

@mkbrechtel

Es ist technisch noch nicht einmal möglich (nur durch Ändern des Versionsparameters), sodass wir alte Umgebungen nicht mehr reproduzieren können.

Nun, das kannst du, du musst nur ein älteres Basis-Image verwenden.

[mkbrechtel (Markus Katharina Brechtel)]

@merefield

Nun, das kannst du, du musst nur ein älteres Basis-Image verwenden.

Wie mache ich das? Ich habe danach gesucht und keine Lösung gefunden…

[merefield (Robert)]

Sie verweisen buchstäblich auf das ältere Basis-Image (erstellt ungefähr zum Zeitpunkt des von Ihnen angestrebten Releases – es muss offensichtlich später sein)

Es gibt Seiten (und Seiten!) davon:

https://hub.docker.com/r/discourse/base/tags

[pfaffman (Jay Pfaffman)]

@Falco

Es gibt einen version-Parameter in der Datei app.yml, der auf die gewünschte Version gesetzt werden kann.

Aber wenn Sie versuchen, eine zu alte Version zu pinnen, funktioniert sie möglicherweise nicht mit aktualisierten Versionen des Discourse-Basis-Images. Ich kann mich nicht an spezifische Beispiele erinnern, aber Dinge wie eine alte Version von Discourse funktionieren nicht mit Ruby 3.2, daher müssen Sie (manchmal) auch discourse_docker pinnen, wenn Sie eine alte Version von Discourse pinnen.

Die sicherste und in den meisten Fällen am wenigsten verschwenderische Lösung ist, ein Image zu erstellen und es in ein Repository zu pushen, anstatt bei jedem Deployment ein neues Image zu erstellen. Und wenn Sie Plugins haben, müssen Sie wahrscheinlich auch jedes davon pinnen.

@Falco

Es kann kompatibel gemacht werden, indem ./launcher bootstrap app ausgeführt und das resultierende Image in eine Container-Registry gepusht und dann das besagte Image über Orchestrierung ausgeführt wird.

Ich habe dies für mehrere Kunden für ECS sowie k8s auf GCP und AWS getan.

@mkbrechtel

also können wir alte Umgebungen nicht mehr reproduzieren.

Ich bin ziemlich sicher, dass Sie das können, wenn Sie auch discourse_docker auf die alte Version pinnen. Wie oben erwähnt, ist es mit Plugins komplizierter, da Sie diese wahrscheinlich auch auf die alten Versionen pinnen müssen. Wenn Sie wirklich alte Versionen pflegen möchten, ist es am besten, sie genau einmal zu erstellen und in ein Repository zu pushen. Ich mache das mit einem Kunden, um Upgrade-Pfade von der aktuellen Produktion zur neuesten zu testen, und es funktioniert reibungslos.