Ich denke, das stimmt 
Warte, bis dieser PR gemergt wurde, und befolge dann die aufgeführten Schritte:
Etwa 100 GB 
mache ich
Da ich mir die Automatisierung dieses Upgrades überlege, wird mir klar, dass zu wissen, wann man dieses „skip-post-deployment“-Verfahren anwendet, ziemlich kompliziert ist.
Bei Single-Container-Installationen gibt es, es sei denn, es liegt eine bizarre Migration vor (das ist die erste, von der ich in meinen 4 Jahren weiß), keinen Vorteil, dies auf diese Weise zu tun. Die meisten Upgrades haben nur wenige Migrationen und wahrscheinlich keine, die rechenintensiv ist.
Bei Two-Container-Installationen ist es immer eine gute Idee, SKIP_POST_DEPLOYMENT_MIGRATIONS zu setzen, da Sie Ihre Site deaktivieren können, wenn die Migrationen den laufenden Container beschädigen. Dadurch geht ein Teil des Gewinns aus der Möglichkeit verloren, den neuen Container zu booten, während der alte weiterläuft. ABER selbst dann enthält nicht jedes Upgrade Migrationen, die Probleme verursachen. Daher führt die durch diesen (sehr begrüßenswerten) Commit bereitgestellte Zwei-Neustart-Lösung wahrscheinlich zu mehr Ausfallzeit (zwei Neustartzyklen) als das Leben am Rande.
Meine aktuelle Überlegung ist, dass eine bessere Lösung darin bestünde, dass Bootstrap die Migrationen immer mit SKIP_POST_DEPLOYMENT_MIGRATIONS=1 durchführt und dann beim ersten Boot eine Migration ausführt. Ich habe jedoch noch keine elegante Lösung dafür, wie das genau funktionieren würde. Gibt es eine schnelle Möglichkeit zu prüfen, ob Migrationen ausstehen? Ich vermute, das Boot-Skript könnte kurz nach dem Start von unicorn eine Bedingung enthalten: „Wenn Migrationen ausstehen, führe eine Migration aus“. Das ist jedoch ziemlich fummelig und für die meisten Installationen die meiste Zeit wahrscheinlich nicht den Aufwand wert.
Definitiv die meiste Zeit nicht wert, aber wenn deine Software-Updates selten (aber manchmal) 10-mal so lange dauern wie üblich, ist das für viele Nutzer ein echtes Problem.
Danach werde ich Discourse-Updates erst mindestens eine Woche nach dem Release durchführen. Natürlich könntest du einwenden, dass ich ein Idiot bin, weil ich nicht von Anfang an gewartet habe, dass ich es mir selbst zuzuschreiben habe und dass ich besser Bescheid wissen sollte – und das ist alles absolut richtig! Trotzdem wäre es ein großer Dienst für alle anderen Idioten da draußen, wenn die Upgrade-Zeiten konsistenter und vorhersehbarer wären.
Alternativ übernimmt das Upgrade über die Benutzeroberfläche von docker_manager dies automatisch.
Das ist großartig! Ich aktualisiere fast nie auf diese Weise, also wäre mir das nie eingefallen. Danke.
Entschuldigung, zur Klarstellung: Wenn wir diese Umgebungsvariable zu unserem App-Container hinzufügen:
Entweder:
SKIP_POST_DEPLOYMENT_MIGRATIONS: true
oder
SKIP_POST_DEPLOYMENT_MIGRATIONS: 1
Wird beim Starten des Launchers dann beim Neuaufbau alle DB-Migrationen übersprungen?
Ist das das richtige Verständnis?
Nicht ganz. Siehe Introducing Post Deployment Migration
Hallo, ich habe es geschafft, alles mit dieser Methode zu aktualisieren (also über die Benutzeroberfläche). Anschließend beginnt es jedoch, diesen Bereitstellungsprozess mit Migrationsanweisungen (denen, die von Anfang an übersprungen wurden) und so weiter durchzuführen, und nach einer Weile schlägt er fehl mit der Meldung, dass das Upgrade nicht erfolgreich war. Das Forum funktioniert jedoch einwandfrei, und das Admin-Dashboard zeigt an, dass alles aktualisiert ist.
Meine Frage ist: Muss ich noch etwas anderes tun? Speziell zu diesem Bereitstellungsprozess: Muss ich ihn über die Kommandozeile ausführen (um Abstürze zu vermeiden)? Gibt es dafür bestimmte Befehle, und wird das Forum während der Ausführung beeinträchtigt?
Hast du noch die relevanten Protokolle? Du musst die Migrationen ausführen, sonst ist die Suche auf der Seite nicht mehr funktionsfähig.
./launcher enter app
bundle exec rails db:migrate
Keine Logs, aber es waren dieselben Abfragen wie zuvor in diesem Thema erwähnt.
Bevor ich diesen Prozess starte und ihn laufen lasse, wird dies die Website vorübergehend unterbrechen (wie ein Rebuild) oder ist es „sicher"? Entschuldigen Sie, dass ich bei diesem spezifischen Problem nachhake, aber dies ist eine Produktionswebsite. Ein Ausfall von 10–15 Minuten ist akzeptabel, jedoch nicht ein Tag oder zwei, und dies muss sorgfältig geprüft werden, falls keine anderen Optionen verfügbar sind.
Wenn Sie bereits auf die neueste Version aktualisiert haben, führt das Ausführen der Migrationen zu keinem Ausfall Ihrer Website. Mit „aktualisiert
Danke. Ich bin schließlich über die UI wieder zu den Updates zurückgekehrt, habe es noch einmal versucht, und die Datenbank-Migrationen nach dem Deployment sind tatsächlich durchgelaufen. Es hat mehrere Stunden gedauert (und viel CPU-Leistung 
), aber sie wurden abgeschlossen und jetzt ist alles vollständig aktualisiert! 