Hallo,\n\ndas Team hat kürzlich die Unterstützung für die Deaktivierung von Long Polling über die Benutzeroberfläche eingestellt. Dies hat die Funktionalität des Bitnami Docker-Images beeinträchtigt, das Passenger verwendet und nicht funktioniert, siehe https://github.com/bitnami/bitnami-docker-discourse/issues/177. Das Bitnami-Image leitet Umgebungsparameter nicht direkt weiter, daher ist dies kaputt, bis jemand das Bitnami-Image erweitert, siehe Sign in to GitHub · GitHub stellte sich mir die Frage, da Discourse bereits nur mit einem Docker-Container vertrieben wird: Gibt es eine Chance, dass das Team ein „Cloud-natives“ Docker-Image pflegt?\n\nDer große Unterschied zwischen dem Bitnami-Image und Ihrem ist die Betriebsart. Moderne Infrastrukturen erwarten, dass die Installation automatisiert werden kann. Normalerweise geschieht dies in k8s mit Helm, aber auch Ansible-Bereitstellungen in eher traditionellen Umgebungen mit VMs würden zum gleichen Ergebnis führen. Was Discourse also mit dem eher vernachlässigten Bitnami-Image auf Augenhöhe bringen würde, wäre das Hinzufügen einer automatischen Installationsroutine und vielleicht sogar die Anpassung der Helm-Vorlage.\n\nDa ich schon hier bin, möchte ich noch ein Feedback zu Discourse selbst und seiner „Cloud-Readiness“ geben:\n\nIm Allgemeinen zeigte sich, als wir versuchten, Discourse in eine reproduzierbare Einrichtung für ein aktuelles Kundenprojekt zu integrieren, recht schnell, dass Discourse nie unter dem Aspekt moderner Infrastruktur entwickelt wurde. Ein Beispiel ist die Notwendigkeit eines gemeinsamen NFS-Speichers. Das ist weder zuverlässig noch skalierbar. Glücklicherweise kann das meiste davon bereits auf S3 umgeleitet werden, aber es bleiben Teile übrig, und das sind die Plugins.\n\nEs gibt drei Möglichkeiten, das Plugin-Problem zu lösen:\n - In der Datenbank gespeicherter ausgewerteter Code (nicht empfohlen)\n - Vorverpackte Sidecar-Container (in Kubernetes-Begriffen als InitContainer verwendet, die in einen leeren Ordner schreiben) schreiben in einen flüchtigen Speicher (d. h. tmpfs) vor dem Start des Discourse-Containers (empfohlen, wenn auch nicht super bequem)\n - Eine Installer-Routine, die beim Start aktuelle Plugin-Informationen und deren Installationsbefehle aus der Datenbank abruft, und eine Watcher/Listener-Routine, um Plugins auch zur Laufzeit zu installieren (nicht empfohlen, da sehr langsam und fehleranfällig)
Ich denke, das wurde hier ziemlich ausführlich diskutiert:
Ehrlich gesagt, da Bitnami es einfach gelöst hat, gibt es nicht viel Grund, viel darüber zu diskutieren. Es wäre keine Raketenwissenschaft, Discourse einfach bereitstellbar zu machen.
Ich möchte nur darauf hinweisen, dass wir viele Discourse-Sites in Cloud-Umgebungen betreiben und keinen NFS-Speicher verwenden. Assets und Uploads werden über Objektspeicher (S3) gehandhabt, während der Quellcode (Core und Plugins) im bootstrapped Container-Image persistent gespeichert wird.
Das wurde bereits beantwortet: Glücklicherweise kann der Großteil davon bereits nach S3 umgeleitet werden, aber es gibt noch Teile, die die Plugins sind. Das Vorab-Erstellen eines Containers zur Verwendung ist eine schlechte Praxis, da dies das Risiko eines nicht ordnungsgemäßen Upgrades über die verwendeten Helm-Charts erhöht.
Können Sie das bitte näher erläutern? Ich verstehe nicht, wie Plugins einen gemeinsamen NFS-Speicher benötigen.
Es tut mir sehr leid, aber wir haben dieses epische Thema bereits, um es zu besprechen.
Ich möchte dies nicht abspalten. Wenn es Ideen gibt, sollten diese diskutiert werden unter: