Kann Discourse regelmäßig Docker-Images bereitstellen, die nicht gebootstrapped werden müssen?

Oh man that’s tragic. So sorry to hear :frowning:

7 „Gefällt mir“

https://meta.discourse.org/t/official-cloud-native-docker-image-from-discourse/228568/8

@sam und dieses Thema machen es deutlich, dies wird nie gelöst werden, obwohl Bitnami es gerade getan hat…

Immerhin haben wir eine Antwort auf unsere Frage bekommen, nämlich nein.

Was ist mit der Vermeidung von Root von vornherein? Die Verwendung von fakeroot zeigt, dass die Haupthindernisse die fest codierten Pfade sind (wie z. B. /var). Ansonsten könnte es, abgesehen von den verschiedenen Fehlern und Problemen, die die aktuelle Einrichtung hat, funktionieren.

Es ist schade, dass eine so großartige Software eine so schlecht konzipierte, obligatorische Einrichtungsprozedur hat, die auf einem allgemeinen Missverständnis der Containerisierung beruht. Es ist mir klar, dass dies mit den besten Absichten geschehen ist; dennoch ist das Ergebnis etwas, das nirgendwo außerhalb einer Hobbyistenumgebung eingesetzt werden kann.

1 „Gefällt mir“

Unser Image läuft als Discourse-Benutzer, und ich denke, das offizielle auch.

Aber auf jeden Fall ist es großartig, dass die „Firmenwelt“ interessiert ist, denn sie hat viel mehr Zeit/Geld als die Hobbyistenwelt :wink: Ich bin sicher, die Community wird Ihre Beiträge zur Verbesserung des Ökosystems zu schätzen wissen!

1 „Gefällt mir“

Das ist sicherlich nicht richtig, wir setzen unser Image mit Nomad auf Maschinenflotten ein, es laufen derzeit über 10.000 Discourse-Container in AWS und Metal.

3 „Gefällt mir“

Die Tools benötigen Root-Zugriff, um ausgeführt zu werden, und sie müssen Zugriff auf das Host-Verzeichnis /var haben.

Ich arbeite oft mit Open-Source-Communities und Unternehmen zusammen, um deren Container-Einrichtung zu verbessern. Ich würde mich freuen, zu helfen und/oder eine Finanzierung in Betracht zu ziehen, um eine vernünftigere containerisierte Einrichtung zu erhalten.

Es ist nicht obligatorisch. Es ist nur so, dass wenn Sie Hilfe bei der Einrichtung benötigen, dies der Weg ist, dies zu tun. Ich habe Kunden geholfen, die zum Beispiel gke, eks, ecs verwenden. Sie können mich gerne kontaktieren, wenn Sie Hilfe bei Ihren speziellen Anforderungen benötigen.

/var ist nicht fest codiert; Ich habe kürzlich mit jemandem zusammengearbeitet, der es in /var/www/discourse hatte (was eine sehr schlechte Idee zu sein schien, da es das Risiko birgt, geheime Daten über das Web preiszugeben, aber es war eine “Richtlinie”).

Es ist nicht schlecht gestaltet, es ist schlecht gestaltet, wenn man es heute und nicht vor einem Jahrzehnt entwerfen würde. Es war damals ein gutes Design, und es funktioniert immer noch, um ihre Infrastruktur zu betreiben, und sogar für viele Leute, die nichts über Systemadministration wissen.

2 „Gefällt mir“

Ich vermute, Sie verlassen sich nicht auf die offiziellen Tools wie discourse-setup, die root-Rechte für die Ausführung benötigen und wahrscheinlich für eine lokale Einrichtung gedacht sind.

Schauen Sie sich den discourse-setup-Quellcode an. Wenn Sie mit der Konfiguration und Leistungsoptimierung von Discourse vertraut sind, ist dies nicht zwingend erforderlich.

Launcher erledigt die Hauptarbeit, um das Image aus dem resultierenden yml zu erstellen.

2 „Gefällt mir“

Alles kann gemacht werden, aber es erscheint mir als unnötiger Aufwand.

  • Verwenden Sie fakeroot vor jedem Befehl
  • /var kann durch Bearbeiten der YAML-Datei geändert werden: sed -i \"s;host: /var/discourse;host: $PWD/discourse;g\" containers/*.yml
  • --skip-connection-test (gefunden durch Betrachten des Codes, da das Skript die Verbindung nicht überprüfen kann, wenn ein Reverse-Proxy vorhanden ist)
  • Ich sehe etwas im Zusammenhang mit certbot, von dem ich bereits weiß, dass ich herausfinden muss, wie ich es deaktivieren kann, da SSL-Offloading normalerweise extern erfolgt
  • Die Ports in containers/app.yml können geändert werden, sodass Ports >= 1024 verwendet werden, aber das scheint nicht auszureichen: Error starting userland proxy: error while calling PortManager.AddPort(): cannot expose privileged port 443

Ich möchte nicht unhöflich sein, aber mehrere Dienste in einem einzigen Container zu betreiben, war schon immer ein schlechtes Design, da man wenig bis gar keine Möglichkeit hat zu wissen, was mit den einzelnen Diensten passiert, einen benutzerdefinierten Protokollparser-Mechanismus außerhalb von Docker einrichten muss, keine nützlichen Healthchecks hat, sich nicht einfach auf eine externe Datenbank verlassen kann usw. Es kann gemacht werden, wenn dies der einzige Dienst ist, den Sie in Ihrem Unternehmen betreiben, aber wenn jeder andere Dienst dies tut, gehen die meisten Vorteile der Verwendung von Containern verloren.

Ich würde gerne einige PRs und Dokumentationen senden, um Discourse in einer Docker-kompatiblen Umgebung ohne Root-Zugriff zum Laufen zu bringen, aber die Entkopplung der Dienste und eine Standardeinrichtung wäre eine große Aufgabe, ohne Garantie, dass sie in den Mainline-Code aufgenommen wird.

Wenn Sie mit grundlegenden Aspekten der Funktionsweise von Discourse nicht einverstanden sind, haben Sie dann erwogen, ein anderes Produkt zu verwenden?

3 „Gefällt mir“

Ok, ich verstehe besser.

Discourse hat eine starke Meinung zu den Werkzeugen für Self-Hosting. Das ermöglicht es ihnen, den meisten nicht so erfahrenen Administratoren, die Discourse bereitstellen möchten, effizienten Support zu bieten. Man kann dem zustimmen oder nicht, ich war auch in der Vergangenheit ein wenig traurig, aber jetzt verstehe ich es besser :slight_smile:

Wenn Sie andere Anforderungen haben als die meisten Leute, die eine schnelle Inbetriebnahme wünschen, dann sind Sie meist auf sich allein gestellt. Wenn man das weiß, ist es in Ordnung :slight_smile:

Wir haben den gleichen Bedarf an einem eigenständigen Discourse-Docker-Image. Wir betreiben es auf Kubernetes mit Minio, es war ein wenig mühsam, es zum Laufen zu bringen, und es ist immer noch viel Aufwand. Wir haben auch einige nette Hilfe von Discourse erhalten, um es so zu machen.

Unsere Arbeit ist hier verfügbar:

https://forge.liiib.re/indiehost/tech/infrastructure/charts/-/tree/master/discourse
(es ist nicht ausreichend dokumentiert, noch getestet, noch gepflegt oder rechtzeitig aktualisiert, oder automatisiert, und wahrscheinlich ein wenig benutzerdefiniert, es ist, was es ist)
Wenn Leute daran interessiert sind, es zu verbessern, zögern Sie nicht, PRs zu stellen oder hier zu chatten: https://matrix.to/#/#libresh:liiib.re

Aber ja, das Discourse-Team hat eine starke Meinung zur Community-Version von Discourse. Man kann dem zustimmen oder nicht, aber sie bieten den meisten Leuten den meisten Support, und das Wenige, was ich gesehen habe, ist ein erstaunlicher Support, daher denke ich, dass es eine gute Entscheidung war :slight_smile:

6 „Gefällt mir“

Dies sind grundlegende Aspekte, wie Discourse verpackt ist, mehr als Discourse selbst, was eine großartige Software ist, aber Sie haben Recht, ich sollte verschiedene Lösungen in Betracht ziehen.

2 „Gefällt mir“

Sie können die Vorlagen für PostgreSQL und Redis (sowie SSL und Let’s Encrypt) gerne entfernen und Ihre eigenen verwenden.

2 „Gefällt mir“

Danke für das Teilen. Ich habe auch GitHub - literatecomputing/docker-compose-discourse: Launch Discourse with docker-compose and similar und Bilder von Bitnami gefunden. Das Hauptproblem ist, dass diese Lösungen nicht offiziell unterstützt werden. Ich frage mich, ob es eine Idee wäre, ein von der Community unterstütztes alternatives Docker-Setup zu haben, anstatt verschiedene benutzerdefinierte Repositories zu haben, da es nicht effizient wäre, die Anstrengungen auf mehrere Orte zu verteilen.

1 „Gefällt mir“

Sie haben Recht, die Einstellungen können tatsächlich geändert werden. Wenn ich es ohne großen Aufwand zum Laufen bringe, werde ich versuchen, einige PRs zu senden, um die bestehenden Werkzeuge oder Dokumentationen zu verbessern, z. B. das Ausführen ohne Root. Das sollte mit den Meinungen des Entwicklungsteams vereinbar sein und gleichzeitig einigen anspruchsvolleren Systemadministratoren Erleichterung verschaffen.

9 Jahre später scheint idiomatische Docker-Images von Bitnamis Discourse abgedeckt zu sein?

Aber anderswo in diesem Forum gibt es Behauptungen, dass es ein RAM-Fresser ist und nicht unterstützt wird. Ich war überrascht, wie viel Reibung es bei der kanonischen Einrichtung immer noch gibt, wenn man versucht, es in der Cloud zum Laufen zu bringen.

Viele Dienste heutzutage wie Redis, Postgres und S3-kompatibler Speicher sind einfach einzurichten und zwischen verschiedenen Hosts wie DigitalOcean, Supabase, AWS usw. zu verschieben, sodass das Backend portabel ist. Die VM, auf der Discourse läuft, sollte ebenfalls einfach zu skalieren/austauschen sein, mit deterministischen Builds. Es ist schade, dass es diesem Ideal so nahe kommt, aber zurückgehalten wird.

Wie ein anderer Benutzer sagte, ist dies überraschend:

Die Logik, die früher im Thread angedeutet wurde, dass dies einfacher zu machen kommerzielle Möglichkeiten behindern könnte, ist eine seltsame. Kommerzielle Interessen werden Mitarbeiter haben, die sich mit den komplexen Builds befassen, sodass dies mehr als jeder andere Solo-Entwickler trifft. Mein persönlicher Anwendungsfall ist, dass ich eine sehr große (nicht gewinnorientierte) Community betreibe. Es fällt also weder unter Hobbyisten nach Größe noch unter kommerzielle nach Einnahmen.

1 „Gefällt mir“

Äh… Ich überlege, ein Forum/eine Community-Plattform einzurichten und habe natürlich an Discourse gedacht (weil ich die Endbenutzererfahrung schätze), aber wieder stoße ich auf das Problem der völlig unfreundlichen Installation/Verwaltung…

Über die Jahre habe ich mich sehr daran gewöhnt, alles mit einer einfachen docker-compose-Datei laufen zu lassen, ein paar zusätzliche Elemente (Datenbank, Minio für S3-kompatiblen Speicher und dergleichen) hinzuzufügen, aber nein… Discourse ist in diesem Fall immer noch sehr unfreundlich.

Es tut mir leid, aber einen albernen “Launcher” zum Starten zu haben?

Und dann der Upgrade-Prozess, der besagt:

Erstellen Sie manuell ein neues Basis-Image, indem Sie ausführen: ./launcher rebuild my_image

Entschuldigung – das Image manuell neu erstellen? Wie WTF… das ist, als hätte man Docker/würde es benutzen, aber eigentlich nicht…

Funktioniert ./launcher rebuild app? Das ist der übliche Befehl.

Außerdem, bist du der Standardinstallationsanleitung gefolgt?

Ich habe nichts Konstruktives zu kommentieren, daher bitte ich Sie, Mastodon-Server, Pixelfed, Moodle… zu aktualisieren. Discourse ist unglaublich einfach.

Ein manueller Befehl ist ein Hindernis :flushed_face:

2 „Gefällt mir“