Ich möchte eine Diskussion über die besten Praktiken für die Durchführung von Kernwartungsaufgaben auf einer Discourse-Instanz eröffnen, um Ausfallzeiten zu minimieren oder zu eliminieren.
Aufgaben wie das Ändern kritischer Ressourceneinstellungen (z. B. UNICORN_WORKERS, DISCOURSE_SIDEKIQ_WORKERS, DISCOURSE_DB_POOL) oder das Anwenden von Hauptupdates erfordern in der Regel einen launcher rebuild app, der eine beträchtliche Zeit in Anspruch nehmen kann, manchmal 30 Minuten oder mehr.
Meine Frage ist: Was sind die empfohlenen Strategien für Systemadministratoren, um diese wesentlichen Updates und Konfigurationsänderungen mit der geringstmöglichen benutzerseitigen Ausfallzeit durchzuführen?
Gibt es fortgeschrittene Techniken wie Blue/Green-Deployments oder andere Zero-Downtime-Deployment-Strategien, die für Discourse unterstützt oder empfohlen werden? Oder ist der Standardprozess rebuild die einzig unterstützte Methode, und der Fokus sollte auf der Optimierung der Rebuild-Zeit selbst liegen?
Ich bin daran interessiert, von allen zu hören, die Erfahrung mit der Verwaltung großer oder stark frequentierter Instanzen haben und wie ihr Workflow für die Wartung aussieht.
Wenn Sie eine Zwei-Container-Installation haben, wird der neue Container erstellt, während der alte läuft. Die Ausfallzeit entspricht nur der Zeit, die zum Starten des neuen Containers benötigt wird. Das einzige Problem ist, dass Sie genügend RAM benötigen, um einen Container zu erstellen, während der andere läuft.
Wenn Sie eine Ausfallzeit von Null wünschen, benötigen Sie einen Load Balancer, der den alten Container am Laufen hält, bis der neue vollständig gestartet ist. Dann fahren Sie den alten Container herunter und führen die Post-Update-Migrationen durch.
Discourse ist so stabil, dass dies für die meisten Installationen ziemlich unnötig ist (aber man könnte es vielleicht für sehr hohe Verfügbarkeitsanforderungen in Betracht ziehen oder wenn man andere hostet?!)
Ich glaube nicht, dass ich in 7 Jahren eine einzige Ausfallzeit aufgrund eines Produktions-“Glitches” hatte …
Die riskantesten Momente im Leben eines Discourse sind immer beim Neubau.
Die Zwei-Container-Einrichtung gibt Ihnen die Möglichkeit, einen neuen Build zu starten, bevor Sie sich dazu verpflichten, obwohl dies natürlich einige Laufzeitfehler nicht abfängt.
Das Problem ist, dass, wenn Ihre Migrationen ausgeführt wurden, Sie sich möglicherweise für den neuen Build entscheiden müssen und daher normalerweise versuchen würden, die Quelle dieser Fehler zu finden und zu beheben, anstatt zurückzurollen.
Im Allgemeinen versuchen die Leute nicht, zurückzurollen …