Null-Downtime-Bereitstellung für Front-End-Ressourcen

Question

Mein Stapel ist Wildfly, eckig, Frühling, RDS, Cloudfront. Frontend-Ressourcen (html/js usw.) werden in der App gespeichert (dh von Wildfly geliefert).

Für Backend und DB mit 2 EC2 hinter ELB ohne Ausfallzeiten bereitstellen, ich kann, aber ich bin nicht sicher, wie dieses Szenario zu behandeln:

• Benutzer alt js/html von unserem Server erhalten -> Bereitstellung von Neue Version fertig -> Benutzer klickt auf etwas, das alte API verwendet (z. B. die neue Version hat einen neuen obligatorischen Parameter)

Gibt es eine Möglichkeit, dies zu vermeiden? Ich kann nur daran denken, den Standardwert für den neuen Parameter zu setzen. Oder würde die API-Versionierung hier Sinn machen?

Eine andere Frage: Was ist, wenn die Frontend-Ressourcen von cloudfront + s3 geliefert werden? Wie kann die Bereitstellung neuer Ressourcen für s3 synchron mit dem Backend erfolgen?

Answer 1

Ich kann nur daran denken, den Standardwert für den neuen Parameter zu setzen. Oder würde API-Versionsverwaltung hier Sinn machen?

Das klingt genau, was API-Versioning lösen soll. Sie würden die API-Versionen jederzeit ändern, wenn eine Änderung die Clients der vorherigen Version stört.

Eine andere Frage: Was ist, wenn die Frontend-Ressourcen von Cloudfront + s3 geliefert werden? Wie die Bereitstellung neuer Ressourcen zu s3 in Synchronisierung mit Back-End zu machen?

Sie gleichzeitig zur Verfügung zu stellen liegt ganz bei Ihnen. Dies ist Teil Ihres Bereitstellungsprozesses, den Sie irgendwie automatisieren müssen. Sie können hier die Versionsverwaltung und die Reihenfolge der Bereitstellung verwenden. Zum Beispiel, wenn Ihr gesamtes Front-End auf S3 eingesetzt wird:

1. Bereitstellen eine neue Version der API, unter einer neuen API-Versionsnummer
2. Deploy neue statische UI Ressourcen
3. Ausgabe einer Cloudfront Cache-Annullierungs
4. Benutzer starten neue Front-End-Ressourcen zu sehen, dass die neue back-End-API-Version

Wenn Ihr Front-End-UI ist eine Mischung aus EC2-Server dynamischer Ressourcen und S3 statischer Ressourcen und die EC2 UI componen Referenz ts und die API werden als Teil der gleichen Bereitstellung aktualisiert. Sie können dann ein Versionspräfix für Ihre statischen Ressourcen in S3 verwenden, damit mehrere Versionen gleichzeitig verfügbar sind. Beispiel:

1. Stellen Sie neue statische UI-Ressourcen in S3 mit einem neuen Versionspräfix bereit. Dies stellt sicher, dass sowohl die vorherige (n) Version (en) der S3-Ressourcen als auch die neue Version gleichzeitig verfügbar sind.
2. Stellen Sie den EC2-App, die beide UI-Komponenten, die EC2 aktualisiert und die API
3. Benutzer die neue Version der App von EC2 starten Laden, die unter einem neuen Version Präfix statische Ressourcen verweisen, die dann Caches Cloudfront und
dient

Offensichtlich sind dies nur ein paar Szenarien und Ihre Situation unterscheidet sich wahrscheinlich in irgendeiner Weise. Im Allgemeinen müssen Sie die Versionierung beliebiger Ressourcen (statische S3-Ressourcen, API-Ressourcen usw.) und eine intelligente Bereitstellungsreihenfolge verwenden, um sicherzustellen, dass der Endbenutzer keine Unterbrechung des Dienstes erkennt.