Fairerweise sollte ich zunächst darauf hinweisen, dass ich neu auf der Plattform und in der Codebasis bin und daher keine Ahnung habe, wie „rebuild
Rebuild ist ein Allzweck-Update, das Folgendes bewerkstelligen kann:
- Aktualisierung der Discourse-Quelldateien
- Aktualisierung von Abhängigkeiten auf Betriebssystemebene, z. B. eine Hauptversion von Ruby
- Aktualisierung auf neuere und inkompatible Versionen von PostgreSQL, wobei das Update automatisch das Datenformat der Datenträger für die neuere Version anpasst
- Aktualisierung des Docker-Images. Als Beispiel: Anfang dieses Jahres wechselten wir von Ubuntu 16.04 auf das neueste Debian, was für den Nutzer völlig transparent ablief – es genügte,
./launcher rebuild appeinzugeben.
Rebuilds sind nicht ständig notwendig; sie sind nur einige Male pro Jahr zwingend erforderlich, wenn ein massives Update von Abhängigkeiten ansteht. Für alle anderen Updates können Sie durch Klicken auf den Web-Updater in der Admin-Oberfläche Updates ohne Ausfallzeit durchführen.
Weitere „DevOps“-Themen finden Sie unter:
und vieles mehr unter #howto:sysadmin
Ich mag mich irren, aber ich finde, @CodeGnomes Frage zu Neuaufbauten ohne Ausfallzeit verdient weitere Untersuchung.
Wenn ich Docker richtig verstehe, könnten folgende Aspekte von Discourse im Hintergrund in einem neuen Container neu aufgebaut werden, während der bestehende Container noch läuft:
- Discourse-Quellcode aktualisieren
- Abhängigkeiten auf Betriebssystemebene aktualisieren, z. B. die Ruby-Hauptversion
- Das Docker-Image aktualisieren. Nur als Beispiel: Anfang dieses Jahres sind wir von Ubuntu 16.04 auf die neueste Debian-Version umgestiegen, und für den Nutzer ist das völlig transparent – man gibt einfach
./launcher rebuild appein.
Bei Änderungen an PostgreSQL, die Breaking Changes verursachen, wird es etwas kniffliger, vor allem wegen des Datenvolumens, das – wie ich annehme – zwischen dem alten und dem neuen Container geteilt wird.
Vielleicht könnte die Seite zu Beginn des Neuaufbaus auf Nur-Lese-Modus gestellt werden, wobei der alte Container sein bestehendes Volume behält und die neu aufgebaute Datenbank in einem neuen Docker-Volume operiert?
Bezüglich des Updates der Discourse-Quelldateien, der Abhängigkeiten auf Betriebssystemebene, des Docker-Basisimages, der Ruby-Gems und ähnlicher Komponenten ist es möglich, den Build in zwei Schritten durchzuführen und die oben genannten Aufgaben im ersten Schritt auszuführen.
Dieser erste Schritt ist unabhängig von der Umgebung und könnte sogar in einer CI-Umgebung ausgeführt werden (so dass Sie in den Staging- und Produktionsumgebungen fast identische Images verwenden können, was mögliche Fehler durch Builds zu unterschiedlichen Zeitpunkten vermeidet, ganz zu schweigen von der reduzierten Ausfallzeit).
Die DB-Migration und die Aufgabe assets:precompile müssten weiterhin auf der Zielmaschine ausgeführt werden. Die DB-Migration ist in den meisten Fällen schnell. Die Aufgabe assets:precompile stellt hingegen ein Problem dar, da sie den meisten Zeit in Anspruch nimmt. Ich vermute, dass dies daran liegt, dass einige Assets Umgebungsdaten benötigen, die in der DB definiert sind, wie z. B. bestimmte CSS-Regeln, um ausgeführt werden zu können.
Es wäre hervorragend, wenn diese Aufgabe in zwei Teile zerlegt werden könnte: Zuerst werden alle Assets kompiliert, die nicht von der Umgebung abhängen, und könnten somit in einer CI-Umgebung ausgeführt werden. Im zweiten Schritt würden dann nur noch die Assets kompiliert, die von Daten in der DB usw. abhängen. Wie technisch aufwendig eine solche Implementierung wäre, weiß ich jedoch nicht.
Ich diskutiere das Bootstrapping des App-Containers in zwei Schritten im folgenden Thema:
Die von mir vorgenommenen Änderungen betrafen lediglich die Aufteilung der Discourse-Web-Vorlage in drei Dateien, wobei die Aufgaben gleich bleiben. Es wäre jedoch großartig, wenn das Discourse-Team dies unterstützen würde, damit ich die Aufgaben nicht aufgrund zukünftiger Änderungen an der Web-Vorlage aktualisieren müsste.