Amazon Web Services bietet je nach Bedarf eine Reihe von Tools für die kontinuierliche Bereitstellung und Verwaltung, wie z. B. Elastic Beanstalk, OpsWorks, Cloud Formation und Code Deploy. Die Grundidee besteht darin, die Bereitstellung und Aktualisierung von Code ohne Ausfallzeiten zu ermöglichen. Sie helfen auch bei der Verwaltung der besten Architekturpraxis mithilfe von AWS-Ressourcen.
Der Einfachheit halber lässt sich eine grundlegende Architektur mit einer 2-Riss-Struktur annehmen. eine Sammlung von Anwendungsservern hinter einem Lastenausgleichsmodul und dann eine Persistenzschicht unter Verwendung einer RDS-DB mit mehreren Zonen.
Das tatsächliche Code-Upgrade für eine ganze Reihe von Instanzen (App-Server) ist einfach zu verstehen. Für einen sehr vereinfachten Überblick aktualisiert der AWS-Dienst jeden Knoten, der wiederum Verbindungen trennt, sodass die betreffende Instanz nicht verwendet wird.
Ich kann jedoch nicht verstehen, wie DB-Upgrades verwaltet werden. Angenommen, wir gehen von Version 1.0.0 zu 2.0.0 einer Anwendung und müssen die DB-Struktur ändern. Normalerweise würden Sie ein Skript oder eine Bibliothek wie Flyway verwenden, um das Upgrade durchzuführen. Wenn jedoch eine Flotte von Servern zu aktualisieren ist, gibt es einen Punkt, an dem sowohl die Anwendungen 1.0.0 als auch 2.0.0 in der Flotte vorhanden sind, die jeweils eine andere DB-Struktur benötigen.
Ich muss verstehen, wie dies tatsächlich erreicht wird (hohe Ebene), um zu wissen, wie die DB-Migration am besten durchgeführt werden kann. Ich denke, es gibt ein paar Möglichkeiten, wie sie das erreichen können, aber ich habe Schwierigkeiten zu sehen, wie sie es schaffen können und sowohl 1.0.0 als auch 2.0.0 erlauben, Daten ohne Verlust persistent zu machen.
Wenn sie die DB-Struktur mit dem ersten App-Knoten-Upgrade migrieren und gleichzeitig eine zwischengespeicherte Version von 1.0.0 erstellen. Benutzer, die mit der 1.0.0-App verbunden sind, behalten die zwischengespeicherte Version der Datenbank bei, und Benutzer, die mit der 2.0.0-Anwendung verbunden sind, bleiben bei der neuen migrierten Datenbank erhalten. Sobald alle App-Knoten migriert sind, werden die zwischengespeicherten Daten in die Datenbank integriert.
Es scheint unwahrscheinlich, dass sie das tun können, da die Zusammenführung ziemlich komplex wäre, aber ich kann keinen anderen Weg sehen. Irgendwelche Hinweise / Hilfe würden geschätzt.
Dies ist ein häufiges Problem, wenn die Anwendungsinfrastruktur in mehrere Anwendungsknoten gelangt. In den alten Tagen konnten Sie Ihre Anwendung für "Wartungsfenster" offline nehmen, während Sie konnten:
Im Jahr 2015 und wirklich seit mehreren Jahren ist dieser Ansatz nicht akzeptabel. Ihre Benutzer erwarten 24/7 Betrieb, also muss es einen besseren Weg geben. Natürlich gibt es die Antwort ist eine Reihe von Mustern für Datenbank Refactorings .
Das Grundkonzept, das Sie immer im Hinterkopf behalten sollten, ist die Annahme, dass Sie zwei gleichzeitige Versionen Ihrer Anwendung verwalten müssen, und es kann keine brechenden Änderungen zwischen diesen beiden Versionen geben . Dies bedeutet, dass Sie eine aktuelle Anwendung (v1.0.0) in Produktion haben und (v2.0.0), die für die Bereitstellung vorgesehen ist. Beide Versionen müssen mit demselben Schema arbeiten. Sobald v2.0.0 vollständig auf allen Anwendungsservern bereitgestellt wurde, können Sie v3.0.0 entwickeln, mit der Sie alle endgültigen Datenbankänderungen durchführen können.