Wir haben das Upgrade vor einigen Monaten erfolgreich durchgeführt. Ich poste unsere Erfahrungen hier, falls jemand in Zukunft die gleiche Frage hat.
Discourse unterstützt Zero-Downtime-Upgrades teilweise durch Post-Deployment-Migrationen. Der gesamte Prozess lässt sich, wie wir ihn verstanden haben, in zwei Schritte unterteilen.
SCHRITT 1: Upgrade auf die neue Version und Ausführung sicherer Migrationen:
- Aktualisieren Sie alle Plugins und Themes, damit sie mit der neuen Version kompatibel sind. (Dies kann je nach Ihrer Einrichtung recht aufwendig sein).
- Erstellen Sie Ihre
web_only.ymlmit folgendem Inhalt:
version: <NEUE_VERSION>
SKIP_POST_DEPLOYMENT_MIGRATIONS=1 - Bootstrap ausführen (
./launcher bootstrap web_only) - Starten Sie Ihre Server neu
SCHRITT 2: Ausführung der Post-Deployment-Migration (hochriskante Migrationen wie das Löschen von Spalten und Tabellen usw.). Zu diesem Zeitpunkt sollte dieser Schritt sicher sein, da alle Server die neue Codeversion ausführen und nicht von den zu löschenden Daten abhängen sollten:
- Erstellen Sie Ihre
web_only.ymlmit:
version: <NEUE_VERSION>
SKIP_POST_DEPLOYMENT_MIGRATIONS=0 - Bootstrap ausführen (
./launcher bootstrap web_only) - Starten Sie Ihre Server neu
Komplikationen:
Wir haben uns entschieden, SCHRITT 1 und SCHRITT 2 an unterschiedlichen Tagen durchzuführen, was zu einigen Problemen führte. Zwischen Version 2.1 und 2.3 gab es ein großes Refactoring des Poll-Modells. Offenbar wurden die meisten Poll-Daten ursprünglich als JSON-Objekt in der Tabelle post_custom_fields gespeichert. In Version 2.3 wurden sie in eine eigene Tabelle namens polls verschoben. Dies erforderte eine Datenmigration, die im Rahmen der Post-Deployment-Migrationen (SCHRITT 2) durchgeführt wurde.
Unser spezifisches Problem bestand darin, dass Umfragen, die vor dem Upgrade erstellt wurden, direkt nach dem Upgrade auf 2.3 defekt waren. Vermutlich ging dies darauf zurück, dass der Code, der sie rendern sollte, das neue Datenmodell voraussetzte. Einige Benutzer bemerkten dies und versuchten, die Umfragen manuell über die Benutzeroberfläche zu aktualisieren. Dabei erstellten sie jedoch Datensätze in der neuen polls-Tabelle. Wie wir später leider feststellen mussten, lösten solche Datensätze während des Bootstrap-Prozesses eine Postgres-Eindeutigkeitsbeschränkung aus, was den Prozess effektiv zum Erliegen brachte.
Um dies zu umgehen, entschieden wir uns, einen Patch einzubringen, der eine bestimmte Poll-Migration übersprang, wenn sie bereits in der Datenbank existierte. Dies war keine perfekte Lösung, da Daten aus post_custom_fields, die für diese Beiträge nie migriert wurden, verloren gehen könnten. In unserem Fall war dies jedoch ein guter Kompromiss, da die Anzahl der betroffenen Fälle in unserem System sehr gering war (zwei Instanzen, die wir beobachten konnten), und es uns ermöglichte, den Bootstrap-Prozess durchzuführen. Die Tests und die Anwendung des Patches brachten jedoch zwei weitere Fragen auf:
-
Wie testen wir die Änderung, bevor wir den PR einreichen?
Wir wollten unseren Code unter denselben Bedingungen testen, unter denen er in der Praxis laufen würde. Das bedeutete, ihn gegen den Bootstrap-Prozess zu testen. Dies ist nicht so trivial wie das Testen von Laufzeitcode-Änderungen, die Sie durch Ausführen der eigenständigen Discourse-App lokal testen können. -
Wie integrieren wir die Änderungen in unser System?
Wir wollten nicht warten, bis der Patch in ein offizielles Discourse-Release aufgenommen wurde, was ein langwieriger Prozess sein kann und uns im Grunde zu einem weiteren Upgrade zwingen würde. Wir hatten bereits Kunden, die sich über bestehende Umfragen beschwerten, und je länger wir warteten, desto höher war die Wahrscheinlichkeit, dass Kunden Umfragen manuell ändern und die Datenintegritätsprobleme verschlimmern.
Also fanden wir einen Weg, die von uns eingeführten Änderungen zu testen, indem wir die Quelle des Repositories änderten, das das Bootstrap-Skript verwendet. Dies erforderte einige Versuche und Irrtümer, da wir mit pups und anderen Tools rund um diesen Prozess nicht sehr vertraut sind. Am Ende haben wir etwas wie dies gemacht.
Dies ermöglichte es uns, zu überprüfen, ob unsere Korrektur wie beabsichtigt funktionierte. Wir konnten auch ein neues Image in der Produktion von unserer eigenen modifizierten Version von Discourse mit dem Patch booten, ohne auf ein offizielles Discourse-Release warten zu müssen.