Könnte mir jemand Ratschläge geben, wie man ein Discourse Docker-Image erstellt, das eine Reihe von Plugins integriert hat, anstatt sie über die Benutzeroberfläche zu installieren?
Hintergrund: Wir möchten die neueste Discourse-Build, d.h. discourse:stable, nutzen, und nach dem, was ich in der Installationsanleitung und anderer Dokumentation gelesen habe, können wir diese als Basis-Image in unserer eigenen Dockerfile verwenden und dann etwas tun wie:
RUN cd /var/www/discourse/plugins && \
git clone https://github.com/discourse/discourse-chat-integration.git
Dies würde das Plugin discourse-chat-integration in den Build aufnehmen. Dann können wir zur Laufzeit alle erforderlichen Umgebungsvariablen übergeben, d.h. DISCOURSE_HOSTNAME, DISCOURSE_SMTP_DOMAIN, DISCOURSE_DB_HOST usw., anstatt diese in der Datei app.yml fest zu kodieren.
Wenn jemand dazu Ratschläge geben könnte, wäre das sehr willkommen.
Sie können Plugins nicht über die Benutzeroberfläche installieren. Sie installieren sie über die YML-Datei. Wenn Sie einen Container verwenden, der noch nicht unterstützt wird und den Sie nicht selbst mit dem Launcher erstellt haben, würden Sie etwas Ähnliches tun, wie Sie vorschlagen.
Aber dieses Plugin ist im Core enthalten (aber vielleicht noch nicht in Stable?).
Sie sind in der YML-Datei nicht wirklich fest codiert. Die YML-Datei wird verwendet, um den Container zu erstellen und zu starten. Sie können ihn erstellen und ihn dann starten, wie auch immer Sie möchten. Sie können ./launcher start-cmd container-name verwenden (oder etwas Ähnliches, Sie können im Launcher nachsehen, ob ich es falsch verstanden habe).
Was ich denke, was Sie tun möchten, ist, weiterhin den Launcher zu verwenden, das Plugin hinzuzufügen, ./launcher bootstrap app für den Container auszuführen und ihn dann so zu starten, wie Sie möchten. Sie können ihn sogar in ein Repository pushen, von wo aus Sie ihn von einer anderen Maschine starten können.
Wir möchten Discourse in unserem Kubernetes-Cluster betreiben und in der Lage sein, das Image in unserem CI/CD-Workflow zu erstellen, daher die benutzerdefinierte Dockerfile. Alle Umgebungsvariablen werden dann über eine ConfigMap und/oder ein Secret an den laufenden Pod übergeben. Ich weiß, dass dies keine unterstützte Installation ist, aber ich versuche zumindest, die unterstützte Methode zum Erstellen eines Discourse-Images für eine bestimmte Version von Discourse zu verwenden, damit wir kontrollieren können, wann wir aktualisieren.
Wenn ich mir das vorhandene launcher-Skript und die samples/web_only.yml ansehe, glaube ich, dass ich die Abschnitte volumes und links auskommentieren kann, da dies in Kubernetes mit einem Persistent Volume und Mount erfolgen würde. Wir würden dann die festen Umgebungswerte in der web_only.yml hinzufügen, den Container mit dem Bootstrap-Befehl erstellen und dann das generierte Image in unser eigenes Repository kopieren.
Für die Discourse-Version können wir überwachen, wann eine neue Version auf Docker Hub verfügbar ist, und dann den Wert base_image in der Datei web.template.yml ändern.
Vielleicht, aber der Container muss normalerweise mit einer Datenbank kommunizieren, um den Container zu erstellen. Es muss nicht die eigentliche Datenbank sein (aber dann müssen Sie die Datenbank migrieren und Assets in Ihrer Pipeline vorab kompilieren).
Sie verwechseln möglicherweise das Problem von Discourse-Upgrades mit dem Aktualisieren der Ressourcen im Basiscontainer.
Es ist mir gelungen, den Container ohne den db:migrate-Hook zu erstellen – ich bin mir nicht sicher, ob es funktionieren wird, da ich es noch nicht getestet habe – es steht auf der To-do-Liste
Für den Wert base_image gehe ich davon aus, dass sich dieser ändert, wenn ein neues Docker-Image veröffentlicht wird. Ich denke daher, ich nehme einfach das, was im Haupt-Branch steht, da dies im Launcher-Skript aufgerufen wird.
Das ist ein guter Anfang! Sie müssen Ihre Datenbank trotzdem migrieren, wenn Sie ein neues Discourse starten.
Es gibt keinen Grund, ein neues Basis-Image zu verwenden, wenn Sie Discourse nicht aktualisieren. Sie kümmern sich also nicht wirklich darum, ob es neue Basis-Images gibt.
Danke Jay. Mein Build hat endlich funktioniert, naja, der Pod ist gestartet Ich habe meinen CI/CD-Build-Prozess geändert, um db:migrate durch die Verwendung einer temporären Datenbank einzubeziehen.
Muss db:migrate immer beim Start ausgeführt werden, da mein Image-Build gegen eine Dummy-DB/Redis erfolgen würde? Mein aktueller Ansatz ist, dass db:migrate und das Vorabkompilieren in einem InitContainer in meinem Pod durchgeführt werden.
Das Image discourse/discourse wäre ideal, wenn es bald produktionsreif ist.
Wenn Sie an Upgrades ohne Ausfallzeiten interessiert sind, sollten Sie SKIP_POST_DEPLOYMENT_MIGRATIONS verwenden und nach dem Beenden der alten Pods die Migration erneut mit etwas wie rake db:ensure_post_migrations db:migrate durchführen.
Derzeit setze ich mehrere Umgebungsvariablen (env vars) in unserem Deployment, z. B. DISCOURSE_BACKUP_LOCATION=s3, und ich gehe davon aus, dass Discourse diesen Wert anstelle dessen verwendet, was über die Benutzeroberfläche festgelegt und somit in der Tabelle site_settings gespeichert wurde – ist das korrekt? Wenn ja, gibt es Tools/Skripte, mit denen ich überprüfen kann, welche Umgebungsvariablen gesetzt sind, und deren Äquivalent in den Site-Einstellungen ermitteln kann?
Der Grund dafür ist: Ich möchte eine laufende Discourse-Instanz migrieren, und um das Risiko zu minimieren, möchte ich die Umgebungsvariablen vorerst nicht setzen, falls ich welche in der neuen Instanz übersehen habe und dies einen nachteiligen Einfluss auf die neue Instanz hätte. Mein Gedanke war, dass ich überprüfen könnte, was in der aktuellen Instanz gesetzt ist, die entsprechenden Einstellungen in der Tabelle erstellen, ein Backup/Restore auf die neue Instanz durchführen und dann die Umgebungsvariablen einzeln entfernen könnte.
Logisch – vielleicht nicht, aber ich dachte, das wäre der vernünftigste Ansatz, falls eine Umgebungsvariable in der laufenden Instanz in der neuen Instanz anders ist/nicht unterstützt wird (laufend = alte Discourse-Version, neu = neueste Discourse-Version).
So ähnlich. Sie überschreiben, was in der Datenbank steht. Sie werden in /var/www/discourse/config/discourse.conf oder etwas sehr Ähnlichem gespeichert.
Großartig. Vielen Dank für all die Hilfe, Jay – das hat wirklich den Unterschied zwischen dem Scheitern und dem Funktionieren dieses Deployments ausgemacht
