Blue/Green-Bereitstellungen mit Azure ServiceFabric

Question

Ich erstelle derzeit eine Anwendung, die das ReliableActors-Framework für Azure ServiceFabric verwendet. Beim Scale-up schaue ich auf Blue/Green-Bereitstellungen. Ich kann sehen, wie man das mit einem staatenlosen System macht. Gibt es eine Möglichkeit, dies mit Hilfe von staatlichen Akteuren zu tun?

Answer 1

Bei Service Fabric handelt es sich um rollende Upgrades und nicht um Deployment-Swaps wie einen VIP-Swap. Sowohl staatenlose als auch Stateful-Dienste werden auf die gleiche Weise aktualisiert, aber es gibt ein paar zusätzliche Nuancen, die Stateful sind, die ich später erwähnen werde.

Durch Upgrades bedeutet das, dass Upgrades für eine Anwendung an Ort und Stelle durchgeführt werden, eine Upgrade-Domain nach der anderen, so dass es keine Ausfallzeiten und keinen plötzlichen Wechsel gibt. Eine fortlaufende Aktualisierung von Service Fabric kann in einem sicheren "verwalteten" Modus erfolgen, in dem die Plattform Integritätsprüfungen durchführt, bevor sie zur nächsten Upgrade-Domäne weitergeht, und wird automatisch zurückgesetzt, wenn die Integritätsprüfung fehlschlägt.

OK, das klingt alles gut. Aber wie machen Sie Blue/Green-Bereitstellungen, wenn Upgrades immer Upgrades durchführen?

Hier finden Anwendungstypen und -versionen statt. Anstelle von zwei "Umgebungen", in denen zwei Anwendungen ausgeführt werden können, verfügt Service Fabric über dieses Konzept versionierter Anwendungstypen, aus denen Anwendungsinstanzen erstellt werden können. Hier ist ein Beispiel, wie das funktioniert:

Sagen wir, ich möchte eine Anwendung namens Foo machen. Meine Foo-Anwendung ist als Anwendungstyp definiert, nennen Sie es FooType. Dies ähnelt dem Definieren einer Klasse in C#. Und wie Klasse in C# kann ich Instanzen meines Typs erstellen. Jede Instanz hat einen eindeutigen Namen, ähnlich wie jede Objektinstanz einer Klasse einen eindeutigen Variablennamen hat. Aber im Gegensatz zu Klassen in C# hat mein FooType eine Versionsnummer. Dann kann ich „registrieren“, um den Anwendungstyp und Version in meinem Cluster:

FooType 1.0 

Damit registriert, ich eine Instanz dieser Anwendung erstellen:

"fabric:/FooApp" of FooType 1.0 

Nun lassen Sie uns sagen, dass ich die Entwicklung der Version 2.0 meiner Bewerbung. So registriere ich Version 2.0 von meiner FooType im Cluster:

FooType 1.0 
FooType 2.0 

Jetzt habe ich beiden Versionen von FooType registriert, und ich habe immer noch eine Instanz von 1,0 Laufe:

"fabric:/FooApp" of FooType 1.0 

Hier ist, wo es Spaß bekommt . Ich kann einige interessante Dinge tun:

Ich kann "Fabric:/FooApp" - eine Instanz von FooType 1.0 - und aktualisieren Sie es auf FooType 2.0. Dies wird ein laufendes Upgrade der laufenden Anwendung sein.

Oder .. Ich kann "Stoff:/FooApp Anwendung" in Ruhe lassen, und erstellen Sie eine neue Instanz meiner Version 2.0-Anwendung:

"fabric:/FooApp" of FooType 1.0 
"fabric:/FooAppv2Test" of FooType 2.0 

Jetzt habe ich zwei Anwendungen, Side-by-Side-Lauf , im selben Cluster. Einer ist eine Instanz von 1.0 und der andere ist eine Instanz von 2.0. Mit einigen Konfigurationen von Ports und Anwendungsendpunkten kann ich sicherstellen, dass Benutzer weiterhin zur Instanz 1.0 wechseln, während ich die Instanz 2.0 teste.

Großartig, so gehen alle meine Tests gegen die 2.0-Instanz, so kann ich jetzt sicher die 1 nehmen.0 Instanz und Upgrade es 2.0 von FooType. Auch hier handelt es sich um ein fortlaufendes Upgrade dieser Instanz (Fabric:/FooApp). Es werden keine Benutzer auf die neue Instanz migriert (Fabric:/FooAppv2Test). Später werde ich gehen und löschen Stoff:/FooAppv2Test, weil das nur zum Testen war.

Einer der Vorteile von blau/grün ist jedoch, dass es möglich ist, zu der anderen Bereitstellung zurückzuschalten, wenn die neue fehlschlägt. Nun, Sie haben immer noch sowohl 1.0 als auch 2.0 von FooType registriert. Also, wenn Ihre Anwendung nach dem Upgrade von 1.0 auf 2.0 falsch funktioniert, können Sie es einfach auf 1.0 "upgraden"! Tatsächlich können Sie eine Anwendungsinstanz zwischen so vielen verschiedenen Versionen ihres Anwendungstyps "upgraden", wie Sie möchten! Und Sie müssen nicht Instanzen aller Ihrer Anwendungsversionen wie in einer swapping-Umgebung ausgeführt haben, haben Sie nur die verschiedenen Versionen registriert und eine einzelne Anwendungsinstanz, die zwischen den Versionen "upgraden" kann.

Ich erwähnte Vorbehalte mit Stateful Services. Bei statusbehafteten Diensten ist es wichtig, dass der Anwendungsstatus - die Daten Ihrer Benutzer - in der Anwendungsinstanz enthalten ist (Fabric:/FooApp). Damit Ihre Benutzer ihre Daten sehen können, müssen Sie sie in dieser Instanz aufbewahren. Aus diesem Grund führen wir rollende Upgrades statt Deployment-Swaps durch.

Dies ist nur die Grundidee. Es gibt andere Möglichkeiten, wie Sie mit Anwendungstypen, -versionen und -instanzen umgehen können, je nachdem, was Ihre Ziele sind und wie Ihre Anwendung funktioniert, aber das ist ein anderes Mal.