Das war ein Hinweis darauf, warum das von mir gepostete Compose-Beispiel nicht das generische PG-Image verwendet hat.
Hmm… aber würden Sie nicht sagen, dass dies andere Wege komplexer macht?
Verstanden! 
Als Docker-Guru sollte das doch alles sehr einfach für dich sein?
3 „Gefällt mir“
Wie ich seit ein paar Tagen zu erklären versuche, macht es die derzeitige Lösung alles andere als einfach 
tl,dr;
Ein einfaches Discourse-Image (ähnlich dem von Bitnami) mit einer Reihe von Umgebungsvariablen zur Konfiguration grundlegender Dinge (wie Zugriff auf Redis, Datenbank) wäre mehr als genug, aber aus irgendeinem Grund ist dies ein absolutes No-Go… 
Ich teile hier Proofs of Concept, um genau das zu tun.
Für ein einfaches Plugin, sicher, aber wir können nicht davon ausgehen, dass ein Plugin auf eine bestimmte Weise aussieht – einige Plugins benötigen zusätzliche Einrichtung, zusätzliche zu installierende Gems, zusätzliche Gem-Abhängigkeiten oder externe Programme, die eine apt-get install-Installation erfordern. Das sollte in ein benutzerdefiniertes Image integriert werden.
Es wäre großartig, dies geschehen zu sehen, aber es ist nicht trivial.
Betreff: Web-Updates, Discourse-Betreiber sollen auch überhaupt keine CLI oder Docker kennen.
1 „Gefällt mir“
Sie müssen nur Ihr eigenes Image mit dem Launcher erstellen (was Sie mit GitHub Actions tun können), es in ein Repository pushen und mit den Umgebungsvariablen starten. Sie müssen immer noch die Datenbank migrieren, Assets vorkompilieren und sie nach S3 pushen. Sie können die Datenbank migrieren und skip_post_deployment_migrations verwenden, damit der alte Container weiterlaufen kann, bis der neue gestartet ist, und ihn dann herunterfahren und den Rest der Migrationen ausführen. Aber das ist viel zu kompliziert für jemanden, der nicht viel mehr über Discourse weiß, als Sie wahrscheinlich wissen wollen. Und es gibt viele, viele Dinge, die schiefgehen können, weshalb die aktuelle Lösung, die aus all den von Ihnen genannten Gründen schrecklich ist, die beste Lösung für Tausende von Menschen ist, die nicht wissen, was Bash ist.
Größtenteils müssen Sie nur ./launcher rebuild app ausführen, außer einmal alle paar Jahre, wenn Sie die Datenbank aktualisieren müssen, dann müssen Sie das zweimal tun. Dieses Maß an Einfachheit können Sie mit docker-compose einfach nicht erreichen. Es besteht die Möglichkeit, dass sie es hätten, wenn docker-compose verwendbar gewesen wäre, als sie anfingen, anstatt ihr eigenes erstellen zu müssen, aber so sind die Dinge nun mal nicht gelaufen.
Wenn Sie das Bitnami-Image verwenden möchten, können Sie das tun, aber hier erhalten Sie nicht viel Hilfe dafür. Ich wette, es funktioniert auch für viele Leute.
1 „Gefällt mir“
hmm… für eine Sprache/Umgebung, die universell und plattformunabhängig sein sollte, erscheint die Abhängigkeit vom zugrunde liegenden OS-Paketmanager ziemlich seltsam… 
Das ist, worauf sich zuvor bezogen wurde, dass Discourse ziemlich fest in der “alten” Art der Verwaltung von PHP-Software/Foren verankert zu sein scheint
Also, um die gesamte Diskussion zusammenzufassen (und sie vielleicht in die erste Nachricht zu schreiben, um sie nicht ad nauseam zu wiederholen ):
- Discourse ist auf “normale Leute” zugeschnitten und konzentriert sich darauf, deren Bedürfnisse zu erfüllen.
- Angesichts der Tatsache, dass Ruby (Umgebung) etwas seltsam ist und (1) es praktisch unmöglich ist, generisch genug offizielle Docker-Images im offiziellen Discourse-Repository bereitzustellen.
korrekt?
Ich würde es ein wenig anders ausdrücken
Da es kein offizielles Image-Angebot (standardmäßig) gibt, gibt es keine andere Möglichkeit, Discourse einzurichten als den Launcher, was den Launcher zur Standard- und im Grunde einzigen (empfohlenen) Methode zur Einrichtung von Discourse macht, könnte man argumentieren, dass die ursprüngliche Aussage immer noch gültig ist
Aber das sind nur Semantiken.
Auf jeden Fall - das Thema ist:
Kann Discourse häufig Docker-Images bereitstellen, die nicht bootstrapped werden müssen?
Aus der gesamten Diskussion scheint hervorzugehen: „Nein, Discourse kann/möchte keine häufigen Docker-Images bereitstellen, die nicht bootstrapped werden müssen“, q.e.d.
Daher würde der Vorschlag, direkt oben einen Kommentar hinzuzufügen, dass ein solches Image nicht bereitgestellt wird, VIEL Ärger ersparen
Das ist eine falsche Annahme.
Wir haben der Bereitstellung eines offiziellen Images mit einer Sammlung spezifischer Plugins noch keine Priorität eingeräumt.
Es ist eine Arbeit, die wir in Betracht ziehen, wir haben viele Ideen, wie wir das tun können, es war einfach keine Priorität des Unternehmens.
5 „Gefällt mir“
Übersetzung von einer Person, die an einem anderen Projekt arbeitet: „Es könnte in Zukunft passieren, aber es könnte auch nicht passieren … da es keine Priorität hat / nicht auf einer Roadmap steht, sind die Chancen, dass es passiert, gering bis null“
Aber im Ernst – eine so grundlegende Einrichtung mit einer gebündelten, sinnvollen Plugin-Sammlung wäre super cool!
Danke für deine Meinung! <3
Zur Information: Ich habe eine Möglichkeit eingerichtet, ein Discourse-Image auf einer Devbox zu erstellen und es auf einem Server bereitzustellen, ohne das Launcher-Skript verwenden zu müssen.
Weitere Diskussionen dazu finden Sie hier in einem von mir erstellten Pull-Request.
Ich habe dies so eingerichtet, dass es vollständig mit Discoures offizieller Docker-Einrichtung kompatibel ist, sodass Sie sich keine Sorgen machen müssen, dass diese Lösung nicht mehr unterstützt wird oder kaputt geht.
Die Kurzfassung, wie das funktioniert: Ich habe das Docker-Image dafür verantwortlich gemacht, Bootstrap-Befehle beim Start auszuführen (anstelle des launcher-Skripts).
1 „Gefällt mir“
Interessanter Ansatz.
Außerdem: interessanter Launcher v2 (GitHub - discourse/launcher: Discourse Launcher CLI)!
2 „Gefällt mir“