ich bin wieder da, um eine etwas ungewöhnliche Frage zu stellen
Ich untersuche weiterhin, wie ich Discourse für meine interne Community installieren kann. In der Vergangenheit habe ich bereits nach der Installation von Discourse mit externem Redis und externem PostgreSQL sowie nach der Verwaltung alles in einem Kubernetes-Cluster gefragt. Die Details findet ihr hier.
Jetzt habe ich eine weitere Unsicherheit, da mir mitgeteilt wurde, dass ich zudem mein eigenes Container-Image erstellen muss, um es mit Helm zum Deployen zu verwenden. Dadurch werde ich die Installation nicht mehr gemäß der offiziellen Dokumentation durchführen können, indem ich die im Cloud-Installationsleitfaden bereitgestellten Skripte verwende.
Ich habe versucht, mein eigenes Image mit dem Bootstrap-Befehl zu erstellen, kann das Docker-Image jedoch nicht selbst starten, da es nach Ruby-Vorlagen sucht und einen Fehler zurückgibt.
Ist es möglich, das Container-Image zu starten, ohne die bereitgestellten Skripte zu verwenden? Ich denke, ich brauche etwas Hilfe, da ich versucht habe, mir das Bash-Skript anzusehen, aber es scheint mir etwas zu fortgeschritten. Ich habe gehofft, dass vielleicht jemand anderes in einer ähnlichen Situation war und mir einen Rat geben könnte.
Um mehr Kontext und weitere Details zu geben:
Ich habe das Launcher-Skript mit dem Befehl bootstrap verwendet, um mein eigenes Image mit meinen Konfigurationen zu erstellen.
Dann besagt die Dokumentation, dass Sie das Launcher-Skript mit dem Befehl run ausführen müssen, um den Container aus dem Image zu erstellen.
Beim Überprüfen des Codes des Skripts stellte ich fest, dass der Docker-Befehl wie folgt aussieht:
Ich bin jedoch nicht in der Lage, alle Variablen in einen Befehl zu übersetzen, den ich ohne das Skript eigenständig ausführen könnte. Vielleicht ist auch der gesamte Ansatz, den ich hier versuche, von Anfang an falsch. Ich wollte es jedoch zuerst selbst testen, bevor ich frage, ob ich das Problem lösen kann, ohne jemanden zu stören.
Wenn ich versuche, das Docker-Image selbst auszuführen, wird der Container beendet. In den Logs sehe ich Folgendes:
Already up to date.
INFO -- : Loading --stdin
/pups/lib/pups/config.rb:23:in `initialize': undefined method `[]' for nil:NilClass (NoMethodError)
from /pups/lib/pups/cli.rb:27:in `new'
from /pups/lib/pups/cli.rb:27:in `run'
from /pups/bin/pups:8:in `<main>'
Discourse ist abhängig von PostgreSQL, das in einem gemeinsam genutzten Volume läuft; und viele weitere wichtige Dateien befinden sich in diesem gemeinsam genutzten Volume (Bilder, hochgeladene Dateien, Backups, Logs und mehr).
Wenn Sie die Integrität des Dateisystems im /shared-Volume gemäß den Discourse-Konfigurationsstandards gewährleisten, können Sie eine Discourse-Docker-Image- und Container-Anwendung problemlos starten und stoppen. Allerdings können Sie die Anwendung (soweit ich weiß) nicht ohne die Discourse-Skripte erstellen (es sei denn, Sie führen eine vollständige Reverse Engineering der Skripte durch und schreiben Ihr eigenes Skript basierend auf den einwandfrei funktionierenden und unterstützten Skripten), da die Skripte dafür verantwortlich sind, eine ausgefeilte EmberJS-SPA (Client-seitige Technologie) auf Basis von Ruby on Rails (Server-seitige Technologie) zu erstellen, ganz zu schweigen von der Verwaltung der Konfiguration der Kernanwendung und aller Plugins. Um ehrlich zu sein, ist es eine ziemlich ausgefeilte Anwendung.
Ja, Sie können einen Discourse-Container starten oder einen Discourse-Container aus einem Discourse-Image erstellen, ohne Skripte zu verwenden, wenn (und nur wenn) Sie bereits ein einwandfreies Discourse-Docker-Image erstellt haben, das den Discourse-Konfigurationsstandards entspricht, einschließlich der Anforderungen an den persistenten Speicher für die Datenbank, Bilder und Uploads, Backups, Protokolldateien usw. Es gibt viele wichtige Dateien, die für Discourse im gemeinsam genutzten Volume erforderlich sind; daher können Sie nicht einfach ein „normales Discourse-Docker-Image“ nehmen und es ohne alle oben genannten erforderlichen Voraussetzungen (und nicht alle wurden oben erwähnt!) zum Laufen bringen.
Danke für die Antwort, das ist sehr hilfreich Ich habe gestern gelesen, warum die Skripte in diesem Topic und ein paar anderen benötigt werden.
Nochmals danke für die ausführliche Erklärung. All diese Informationen helfen mir zu verstehen, wie ich meinen eigenen Workflow erstelle, um den erforderlichen Standards zu entsprechen
Es kann für jeden sehr verwirrend sein, der (1) kein Ruby on Rails-Entwickler und (2) kein EmberJS-Entwickler ist.
Im Grunde bauen Sie eine gedockerte Ruby on Rails-Anwendung für den Produktionsbetrieb (die Server-seitige Technologie), die das Fundament für eine erstklassige EmberJS-SPA-Anwendung (die Hauptbenutzeranwendung) bildet; und darauf aufbauend erhalten Sie ein komplettes Open-Source-Konfigurationsmanagementsystem für den gesamten Quellcode, das von einem sehr talentierten und erfahrenen Team von Web-Experten gewartet wird, die seit langem in dieser Umgebung programmieren. Darüber hinaus können Sie auch professionelles Hosting und individuelle Entwicklung innerhalb des Discourse-Geschäftsökosystems erhalten.
Bin gerade darauf gestoßen. Meinst du damit, dass ich die Anwendung und die Datenbank nicht auf physisch verschiedenen Hosts betreiben kann, die absolut nichts gemeinsam haben?
Nein, das ist nicht der Fall. Der Betrieb von Discourse mit einer dedizierten externen Datenbank ist ein unterstützter und dokumentierter Anwendungsfall.