Upgrade auf 3.1.0.beta2 bei typischer Multi-Container-Installation erfordert zusätzliche Ausfallzeit

Installation
1

Ich habe meine Websites von 3.1.0.beta1 auf 3.1.0.beta2 aktualisiert und nachdem ich die neue Version gebootstrapped hatte, aber bevor ich die alten App-Container zerstört und neue gestartet hatte, begann mindestens eine dieser Websites, den Benutzern die generische Fehlerseite anzuzeigen.

Ich habe es auf meiner Testseite oder den anderen Websites, die ich betreibe, nicht bemerkt, aber es ist möglich, dass es passiert ist und ich es nicht gesehen habe.

Auf jeden Fall war für mich in mindestens einem Fall der “Zero Downtime”-Update-Prozess nicht erfolgreich.

2

9 Beiträge wurden in ein neues Thema aufgeteilt: Probleme mit dem selbst gehosteten Upgrade auf 3.x: kein Rollback möglich

3

Ein Beitrag wurde in ein bestehendes Thema eingefügt: Probleme beim Upgrade einer selbst gehosteten Installation auf 3.x: Kein Rollback möglich

12

Ich möchte wiederholen, dass ich nicht das GUI-Update-Tool verwendet habe. Ich habe eine Multi-Container-Installation. Ich habe Folgendes ausgeführt:

git pull
./launcher bootstrap app
./launcher destroy app && ./launcher start app
./launcher cleanup

(Ich verwende app für die Web-App, auch bei Multi-Container-Installationen. Ich weiß, dass dies keine übliche Praxis ist. Ich hasse es, web_only zu tippen)

Einige Zeit nachdem ich bootstrap gestartet hatte und bevor ich die App zerstört hatte, zeigte die alte Version, die gegen die neue Datenbank lief, nur einen Fehlerbildschirm an. Ich erinnere mich nicht mehr an den Inhalt und habe keine längere Ausfallzeit verursacht, indem ich angehalten habe, um einen Screenshot zu machen, bevor ich destroy/start ausgeführt habe, aber es war nur Text auf Weiß und nicht die Systemwartungsseite. Ich habe dies nur ein paar Mal zuvor gesehen: Wenn bootstrap als Teil des asynchronen “Zero-Downtime”-Rebuilds db:migrate ausführt, schlägt die alte, noch laufende Software aufgrund einer Schema-Inkonsistenz fehl.

Was ich gesehen habe, war das, was im Falle einer Datenbankinkonsistenz passiert. Das ist weitaus besser, als ahnungslos weiterzumachen und die Datenbank zu beschädigen! Als ich gepostet habe, wollte ich darauf hinweisen, dass dies einer dieser seltenen Fälle ist, in denen das Anwenden eines Punkt-Updates (hier von 3.1.0.beta1 auf 3.1.0.beta2) eine Schema-Inkompatibilität zwischen dem 3.1.0.beta1-Code und der Datenbank nach Ausführung des 3.1.0.beta2 db:migrate verursacht, wie es selten, aber gelegentlich bei den normalen Low-Downtime-Updates in der Multi-Container-Bereitstellung vorkommt.

Meine Erfahrung unterscheidet sich von dem Fehler, der mit Ruby im GUI-Updater gemeldet wurde. Es ist ein völlig unabhängiges Problem. Ich erkenne an, dass mein Beitrag aus der Ankündigung in einen allgemeinen Thread “Probleme mit” verschoben wurde, aber ich möchte klarstellen, dass der Grund, warum ich ihn in die Ankündigung gepostet habe, darin bestand, andere Self-Hosters wie mich zu warnen, wenn sie die Ankündigung sahen, dass dieses spezielle Update eine solche Auswirkung haben könnte.

Meine Nachricht war keine Beschwerde über einen Fehler oder gar ein Problem. Sie war nur als Hinweis auf einen normalen, aber seltenen Fall gedacht, der mit dieser speziellen Veröffentlichung verbunden ist und in den Versionshinweisen nicht hervorgehoben wurde.

Die Beschwerden darüber, dass der Docker-Manager nicht erkennt, dass er nicht aus dem Image heraus aktualisieren kann, stehen in keinem Zusammenhang mit meinem Versuch, anderen Self-Hosting-Administratoren eine hilfreiche Benachrichtigung zukommen zu lassen.

Es wäre sinnvoll, diese zusammenhanglosen Probleme in unabhängige Threads für unabhängige Probleme aufzuteilen. EDIT von @supermathie: Erledigt

1 „Gefällt mir“
13

Führen Sie eine zweistufige Migration mit Introducing Post Deployment Migration durch?

Dieses Muster ist entscheidend, wenn Sie z. B. ein Blue-Green-Deployment durchführen und die vorherige Version weiterhin funktionieren muss.

1 „Gefällt mir“
14

Ich denke, das beantwortet die Frage. Das launcher-Skript unterstützt keine SKIP_POST_DEPLOYMENT_MIGRATIONS.

Auch hier melde ich keinen Fehler. Ich versuche nur, andere mit der Standard-Multi-Container-Installation, die den normalen dokumentierten Prozess für die Verwendung von launcher mit einer Multi-Container-Installation verwendet, davor zu warnen, dass diese anders ist als ihre übliche Erfahrung.

Wirklich, ehrlich, ich meine es ernst, dies ist kein Fehlerbericht!

Wenn ich Blue/Green-Deployment mit launcher wünsche, sollte ich einen PR für launcher bereitstellen, um es zu implementieren. :smiling_face:

1 „Gefällt mir“
15

Ich habe mir den „Problem“-Teil des Thementitels nicht ausgedacht; das geschah, als mein Kommentar aus dem Ankündigungsthread verschoben wurde. Ich habe den Titel nun geändert, um klarzustellen, hoffe ich, dass ich mich nicht über ein Problem beschwere. :smiling_face:

1 „Gefällt mir“
16

Alles gut!

Ich vermute, dass eine sehr kleine Anzahl von Benutzern Multi-Container Blue/Green verwendet, aber wir wären dankbar für Vorschläge, wie das gemacht werden kann.

Und auch, wie man das Thema findet, das ich verlinkt habe; Ich vermute, es ist nicht einfach zu finden, wenn man nicht bereits weiß, dass es existiert.

2 „Gefällt mir“
17

Ich hatte das SKIP_POST_DEPLOYMENT_MIGRATIONS-Dokument gesehen. Was ich wirklich verpasst hatte, war dieser Beitrag, der zeigt, wie man Zero-Downtime-Deployments mit launcher durchführt:

Jetzt muss ich darüber nachdenken, da ich weiß, dass es machbar ist. Wenn ich es tue, werde ich MKJ's Opinionated Discourse Deployment Configuration mit dem, was ich tue, aktualisieren.

Ich hatte viele Schwierigkeiten, mich dafür zu begeistern, wenn ich vier, manchmal vierinhalb Neunen Verfügbarkeit für einen Dienst biete, den ich in meiner Freizeit kostenlos betreibe. Es ist ein Beweis für die Qualität der Discourse-Entwicklung, dass ich das mit einer Tests-bestanden-Richtlinie tun kann, einschließlich Dingen wie der zusätzlichen Minute oder so Ausfallzeit, die ich dieses Mal gesehen habe, und manchmal dem Neustart des Hosts für Sicherheitsupdates.

3 „Gefällt mir“
18

Das Ansible-Skript, das dashboard.literatecomputing.com verwendet, führt nach dem Starten des neuen Containers eine Rake-Aufgabe aus, um die Post-Migrationen durchzuführen. Es setzt voraus, dass SKIP_POST_DEPLOYMENT_MIGRATIONS in web_only.yml aktiviert ist. Ich mache dies nur auf Websites, von denen ich weiß, dass sie von meinen Skripten verwaltet werden, da es eine Zeitbombe ist, wenn man nicht versteht, wie es funktioniert.

Beachten Sie, dass bei vielen Upgrades das Bootstrapping des neuen Containers die laufenden Container nicht beeinträchtigt, bei einigen jedoch schon. Es ist nicht ungewöhnlich, dass ein Upgrade so migriert, dass der alte Container die Datenbank nicht verwenden kann (ohne SKIP_POST_DEPLOYMENT_MIGRATIONS zu verwenden).

2 „Gefällt mir“