Hilfe bei der "Zero Downtime"-Einrichtung

Unterstützung Installation
1

Ich versuche, das Konzept der „Zero Downtime"-Konfiguration zu verstehen. Meine aktuelle Einrichtung umfasst mehrere Discourse-Instanzen für verschiedene Communities. Beide verfügen über eine Daten-/Web-Container-Konfiguration mit zwei Containern. Auf Host-Ebene läuft ein Nginx, der die SSL-Terminierung übernimmt und eine Socket-Verbindung verwendet, die an den Nginx des Containers weitergeleitet wird.

Ich habe folgende zwei Themen gefunden, die für mich interessant sind:

Ich versuche nun, diesen Prozess zu verstehen. Es scheint, als würde dabei einiges an Vorwissen vorausgesetzt. Jede Hilfe, die hier gegeben werden kann, wäre großartig.

Das Erste, was ich verstehen möchte, ist, wie man erkennt, wann ein Daten-Container aktualisiert werden muss. Es scheint Fälle zu geben, in denen man den Web-Container nicht einfach neu aufsetzen kann. Wie kann ich mit Sicherheit feststellen, wann dies der Fall ist? Handelt es sich dabei um alle Fälle, in denen die Upgrade-Option im Admin-Bedienfeld für Upgrades ausgegraut ist, sowie um potenziell benutzerdefinierte Arbeiten mit Themes und Plugins? Könnte ich dies mit Sicherheit feststellen, indem ich die Datenbank-Schema-Migrationen durchgehe? Müsste ich eine Staging-Umgebung einrichten und es einfach versuchen, um mit Sicherheit zu wissen?

Als Nächstes möchte ich wissen, wie man ein Zero-Downtime-Upgrade durchführt. Wie ich die beiden Links verstehe, würde man ohnehin einen Neuaufbau des Daten- und des Web-Containers durchführen? Ich kann das nicht entschlüsseln. Wäre ich für die Umsetzung von Zero Downtime am Ende auf separate Daten-/Web-Container angewiesen?

Jede Anleitung wäre fantastisch! Wahrscheinlich könnte ich viele Stunden damit verbringen, etwas herauszufinden, das anscheinend funktioniert, aber ich würde lieber auf den Schultern von Riesen stehen und nicht auf die harte Tour (in der Produktion) herausfinden müssen, wo die Randfälle liegen, wenn es irgendwie möglich ist.

Falls Sie weitere Informationen zu meiner speziellen Einrichtung benötigen, bitten Sie bitte um Klärung. Ich werde direkt antworten und diesen Beitrag aktualisieren.

Vielen Dank.

2 „Gefällt mir“
2

Ich weiß nicht viel über „Post-Deployment-Migrationen“, aber laut dem, was ich hier auf Meta gelesen habe, ist eine Möglichkeit, dies zu erreichen, die Verwendung von 3 Containern: 1 Daten- und 2 Web-Container. Sie aktualisieren den nicht laufenden Web-Container und schalten ihn nach dem Update auf den aktiven um.

3 „Gefällt mir“
3

Das ergibt meiner Meinung nach Sinn. Der Data-Container führt also kein Rebuild über den Launcher aus? Ich würde die Lastverteilung einfach auf Host-Ebene über Nginx steuern. Lass mich prüfen, ob ich das so hinbekomme:

Data-Container:

./launcher enter data_container 
SKIP_POST_DEPLOYMENT_MIGRATIONS=1 rake db:migrate

Web-Container:

./launcher rebuild web_container1 && \
sleep 60 && ./launcher rebuild web_container2

Data-Container:

rails generate post_migration
SKIP_POST_DEPLOYMENT_MIGRATIONS=0 rake db:migrate

Klingt das vernünftig?

4

Das hängt alles davon ab, welche Aktualisierungen am Datencontainer vorgenommen werden müssen.

Das Update auf Postgres 12 ist ein gutes Beispiel für unvermeidliche Ausfallzeiten. Selbst wenn Sie einen duplizierten Datencontainer hätten, müssten Sie Ihre duplizierte Seite während des Datenbank-Updates nur lesend betreiben.

Der einzige Weg, um niemals Ausfallzeiten zu haben, besteht darin, niemals zu aktualisieren. Updates über /admin/upgrade bei einer einzelnen Container-Installation sind bereits ausfallfrei. Updates per SSH, beispielsweise wenn das Basis-Image aktualisiert werden muss, führen je nach Budget und Komplexitätstoleranz zu unterschiedlich langen Ausfallzeiten.

Der beste Weg, um Ausfallzeiten zu vermeiden, ist die Erstellung einer Staging-Kopie. Andernfalls besteht nach jedem Update ein geringes Risiko für Ausfallzeiten, wenn Plugins oder Anpassungen auf Kompatibilitätsprobleme stoßen.

2 „Gefällt mir“
5

Okay. Um sicherzustellen, dass ich kein größeres Problem bekomme, führe ich einen Testlauf in der Staging-Umgebung durch und beobachte die Ergebnisse. Ich würde also das oben genannte Verfahren versuchen und prüfen, ob der Datencontainer fehlschlägt.

Wenn ja, könnte meine Staging-Umgebung aus 1 Datenbank und 1 Webserver bestehen, während die Produktion aus 2 Datenbanken und 2 Webservern besteht. Im schlimmsten Fall wäre der Ablauf in der Produktion, wenn man ihn zuerst in Staging versucht:

  • auf schreibgeschützt setzen
  • cp -rp shared/data1 nach shared/data2 kopieren
  • data2 aktualisieren
  • web2 herunterfahren
  • data2 mit web2 verknüpfen
  • web2 neu aufbauen
  • data2 mit web1 verknüpfen
  • web1 neu aufbauen
  • schreibgeschützt deaktivieren

Macht das Sinn?

6

Das hängt von deiner Definition von Ausfallzeit ab.

Wenn Benutzer nicht auf die Seite zugreifen können, ist das offensichtlich eine Ausfallzeit.

Wenn sie sich nicht registrieren, Beiträge verfassen, antworten oder liken können, würdest du das dann als Ausfallzeit betrachten?

Bei einer großen Community sind die Kosten für den Betrieb mehrerer Datencontainer auf SSD erheblich. Hast du einen externen PostgreSQL-Server wie Amazon RDS in Betracht gezogen?

1 „Gefällt mir“
10

Die Art von Details, auf die @Stephen hinweist, sind wirklich wichtig. Denn wir müssen verstehen, was Zero Downtime bedeutet. Beispielsweise könnte ich eine Zero-Downtime-Anforderung durch folgendes Vorgehen umgehen:

Ich definiere Zero Downtime so, dass ich einem Nutzer bei einer gültigen Anfrage niemals einen HTTP-Statuscode außer 200 zurückgebe (wobei 300er und 400er Codes bei Bedarf offen bleiben). Anschließend stelle ich Discourse auf einem 10-Dollar-Droplet in einer One-Container-Lösung bereit und füge Add an offline page to display when Discourse is rebuilding or starting up hinzu, um 500er-Fehler zu vermeiden. Auf diese Weise zeige ich keine Seite, die offline war.

Würde ich in einem rationalen Zustand denken, dass dies Zero Downtime ist? Niemals. Funktioniert es wie vorgeschlagen? Natürlich. Und ich könnte sogar einen Standby-Server in einer anderen Region hinzufügen, um es noch zero-downtime-sicherer zu machen.

Deshalb sind Qualifizierung und Semantik wichtig. Es ist nicht dasselbe, immer etwas anzuzeigen, wie immer Funktionalität auf der Seite zu gewährleisten.

3 „Gefällt mir“
12

Helfen Sie uns bitte zu verstehen. Was benötigen Sie, um Ihre Definition von „Zero Downtime

14

Diese Diskussion wurde etwas hitzig und vom Thema ablenkend. Bitte denkt daran, euch bei der Besprechung eines Themas gegenseitig mit Respekt zu begegnen. Klärende Fragen werden gestellt, um eine präzisere Antwort zu geben, da die Konfigurationen und Ziele aller unterschiedlich sind.

15

Dieses Thema wurde automatisch nach 13 Stunden geöffnet.