microsoft - Implementaciones azules/verdes con Azure ServiceFabric
porta azure (1)
Service Fabric se trata de actualizaciones progresivas, en lugar de intercambios de implementación, como un intercambio VIP. Tanto los servicios sin estado como con estado se actualizan de la misma manera, pero hay algunos detalles adicionales que mencionaré más adelante.
Al implementar actualizaciones, me refiero a actualizaciones en una aplicación, un dominio de actualización a la vez, para que no haya tiempo de inactividad ni cambio repentino. Una actualización progresiva en Service Fabric se puede realizar en un modo "administrado" seguro donde la plataforma realizará comprobaciones de estado antes de pasar al siguiente dominio de actualización, y se retrotraerá automáticamente si fallan las comprobaciones de estado.
OK, todo eso suena bien. Pero, ¿cómo se realizan las implementaciones azul / verde cuando las actualizaciones siempre están aumentando las actualizaciones?
Aquí es donde entran los tipos de aplicaciones y la versión. En lugar de tener dos "entornos" que pueden contener dos aplicaciones en ejecución, Service Fabric tiene este concepto de tipos de aplicaciones versionadas a partir de las cuales se pueden crear instancias de aplicaciones. Aquí hay un ejemplo de cómo funciona esto:
Digamos que quiero hacer una aplicación llamada Foo. La aplicación My Foo se define como un tipo de aplicación, llámala FooType. Esto es similar a definir una clase en C #. Y como clase en C #, puedo crear instancias de mi tipo. Cada instancia tiene un nombre único, similar a cómo cada instancia de objeto de una clase tiene un nombre de variable único. Pero a diferencia de las clases en C #, mi FooType tiene un número de versión. Luego puedo "registrar" el tipo de aplicación y la versión en mi clúster:
FooType 1.0
Con eso registrado, puedo crear una instancia de esa aplicación:
"fabric:/FooApp" of FooType 1.0
Ahora, digamos que desarrollo la versión 2.0 de mi aplicación. Entonces registro la versión 2.0 de mi FooType en el clúster:
FooType 1.0
FooType 2.0
Ahora tengo ambas versiones de FooType registradas, y todavía tengo una instancia de 1.0 ejecutándose:
"fabric:/FooApp" of FooType 1.0
Aquí es donde se divierte. Puedo hacer algunas cosas interesantes:
Puedo tomar "fabric: / FooApp" - una instancia de FooType 1.0 - y actualizarlo a FooType 2.0. Esta será una actualización progresiva de esa aplicación en ejecución.
O ... puedo dejar "fabric: / FooApp" solo, y crear una nueva instancia de mi aplicación de la versión 2.0:
"fabric:/FooApp" of FooType 1.0
"fabric:/FooAppv2Test" of FooType 2.0
Ahora tengo dos aplicaciones, corriendo una al lado de la otra, en el mismo clúster. Uno es una instancia de 1.0 y el otro es una instancia de 2.0. Con algunas configuraciones de puertos y puntos finales de aplicaciones, puedo asegurar que los usuarios todavía vayan a la instancia 1.0 mientras pruebo la instancia 2.0.
Genial, por lo que todas mis pruebas pasan frente a la instancia 2.0, así que ahora puedo tomar la instancia 1.0 y actualizarla a 2.0 de FooType. Nuevamente, esta es una actualización progresiva de esa instancia (fabric: / FooApp), no está migrando usuarios a la nueva instancia (fabric: / FooAppv2Test). Más tarde iré y borraré fabric: / FooAppv2Test porque eso fue solo para probar.
Sin embargo, uno de los beneficios del azul / verde es poder volver a la otra implementación si falla la nueva. Bueno, todavía tienes 1.0 y 2.0 de FooType registrado. Entonces, si su aplicación comenzó a funcionar mal después de la actualización de 1.0 a 2.0, ¡simplemente puede "actualizarla" de nuevo a 1.0! De hecho, puede "actualizar" una instancia de aplicación entre tantas versiones diferentes de su tipo de aplicación como desee. Y no necesita tener instancias de todas las versiones de sus aplicaciones ejecutándose como lo hace en un entorno de intercambio, solo tiene las diferentes versiones registradas y una única instancia de aplicación que puede "actualizarse" entre versiones.
Mencioné advertencias con servicios con estado. Lo más importante que debe recordar con los servicios stateful es que el estado de la aplicación (los datos de sus usuarios) está contenido en la instancia de la aplicación (fabric: / FooApp), por lo que para que los usuarios vean sus datos, debe mantenerlos en esa instancia. Es por eso que hacemos actualizaciones continuas en lugar de intercambios de implementación.
Esta es solo la idea básica. Existen otras maneras de jugar con tipos de aplicaciones, versiones e instancias, dependiendo de cuáles sean sus objetivos y cómo funciona su aplicación, pero eso es para otro momento.
Actualmente estoy compilando una aplicación utilizando el marco de ReliableActors en Azure ServiceFabric. A medida que ampliamos, estoy buscando hacer implementaciones azul / verde. Puedo ver cómo hacer esto usando un sistema sin estado. ¿Hay alguna manera de hacer esto usando actores estatales?