@pfaffman Wenn du dir die von mir vorgenommenen Änderungen ansiehst: Ich habe die Anweisungen für die Web-Vorlage in discourse_docker nicht geändert, sondern sie lediglich in drei Dateien aufgeteilt. Das ist im Übrigen das Einzige, was ich eigentlich beantragt habe: Eine Datei führt Anweisungen aus, die unabhängig von der Umgebung sind, wie etwa die Installation von Ruby-Gems, das Abrufen des Discourse- und Plugin-Repositories und Ähnliches. Eine zweite führt Validierungen durch, und die dritte erledigt umgebungsspezifische Aufgaben, wie beispielsweise die Datenbankmigration und das Vorkompilieren der Assets.
Die Komplexität, die meiner Meinung nach hinzukommt, besteht darin, dass das Discourse-Team bei Änderungen an diesen Dateien prüfen muss, ob sie umgebungsspezifisch sind (z. B. von Datenbankeinhalten abhängig) oder nicht, und darauf aufbauend festlegen, in welche Datei sie aufgenommen werden sollen.
Die offizielle Installation würde genauso funktionieren wie heute, mit dem Unterschied, dass sie die drei Vorlagen in der Datei app.yml enthalten würde (oder die Datei templates/web.template.yml diese drei Vorlagen einbinden würde, falls dies möglich ist, und in diesem Fall würde sich für den Benutzer nichts ändern), anstatt dies in mehr als einem Schritt zu erledigen (es hätte zwar nicht die Vorteile der Zwei-Schritt-Installation, würde aber exakt so funktionieren wie aktuell, sodass keine Breaking Changes entstehen).
Ich weiß, dass Sysadmin-Themen wirklich komplex sein können, aber ich habe versucht, es so einfach und direkt wie möglich zu gestalten, unter Berücksichtigung der aktuellen Vorgehensweise, um unnötige Komplexität zu vermeiden (deshalb habe ich nichts über Kubernetes erwähnt, die Dienste in einer docker-compose-Datei zu trennen oder Ähnliches, da dies große Änderungen erfordern würde, und stattdessen mich an der offiziellen Installationsmethode orientiert).