Äh… 
Das Skript benötigt nicht einmal Zugriff auf /var/discourse (warum auch?).
Das gesamte Problem ergibt sich aus ein paar Dingen:
- Großes Missverständnis darüber, was Docker ist, wie es funktioniert und was es ermöglicht
- Verknüpfung der Vorstellung, dass Docker = Docker-Compose (ist es nicht!)
Sie können eine vollständig in sich geschlossene Einrichtung haben, die die Host-Umgebung praktisch nicht berührt…
Nach einigem Nachforschen scheint es, dass das gesamte “Setup”-Skript erstellt wurde, um die Installation für die absolut nicht-technische Person so einfach wie möglich zu gestalten. Es prüft, leitet den Benutzer an und richtet alles ein. Das mag eine nette Sache sein, aber es bricht vollständig zusammen, wenn man versucht, auch nur den kleinsten Schritt vom vorgesehenen Weg abzuweichen.
Bei der grundlegendsten Einrichtung benötigen Sie möglicherweise nicht einmal Zugriff auf Host-Verzeichnisse – alles wird in einer begrenzten Umgebung enthalten sein (das Image wird verwendet, um den Container zu erstellen, und der gesamte erforderliche Speicher wird über Docker-Volumes verwaltet [es gibt Probleme, wenn Sie woanders migrieren oder auf die Dateien zugreifen möchten, aber wir sprechen hier von den Grundlagen]).
Es versucht auch sicherzustellen, dass DNS korrekt ist, versucht, Zertifikate, Reverse-Proxy, SMTP und dergleichen einzurichten – wieder, völlig in Ordnung, diese einfache Einrichtung bereitzustellen.
ABER!
Das Problem ist NICHT, das wegzuwerfen, sondern ZUSÄTZLICH ein reines Docker-Image bereitzustellen (es ist bereits vorhanden, es wird von den Skripten und Vorlagen verwendet, die das Skript verwendet! discourse_docker/templates/postgres.template.yml at main · discourse/discourse_docker · GitHub & discourse_docker/launcher at main · discourse/discourse_docker · GitHub) mit
- ordnungsgemäßer Versionierung: Sie kennzeichnen das Image mit der veröffentlichten Discourse-Version (3.4.5 oder was auch immer)
- vernünftiger, einfacher Dokumentation der erwarteten Umgebungsvariablen (die die Datenbank-/Redis-/etc.-Konnektivität steuern) und möglicher Pfade/Volumes, die auf den Host gemountet werden können.
Nur das…
Werfen Sie einen Blick auf den oben genannten Miniflux-Leitfaden: Miniflux Installation with Docker – er gibt Ihnen Details über das Image (und welche Repositories sie bereitstellen) und mögliche Umgebungsvariablen zur Konfiguration.
Oder das MySQL-Docker-Image: https://hub.docker.com/_/mysql – dasselbe – ein Leitfaden, der erklärt, was konfiguriert werden kann (siehe insbesondere den Abschnitt: “Umgebungsvariablen”).
Niemand sagt: “Sie müssen den MySQL-Launcher verwenden, um das MySQL-Image zu erstellen, damit Sie es verwenden können”, oder Redis übrigens – in diesem Fall verwenden Sie einfach vorhandene Images, und das ist der Hinweis und der Kern der Verwendung von Docker. Doch im Fall von Discourse ist dies plötzlich eine “schlechte” Lösung und alle rufen: “Sie müssen Ihr eigenes Image erstellen!” – warum!?