Uno de los desafíos más importantes en el despliegue continuo es el despliegue en sí, que lleva el software desde la etapa final de prueba a la producción en vivo. Por lo general, esto debe suceder lo más rápidamente posible para minimizar el tiempo de inactividad. El enfoque de implementación Blue-Green nos ayuda con este problema al garantizar que se tengan dos entornos de producción, lo más idénticos posibles, minimizando el tiempo de inactividad en el despliegue.
En este caso, uno de los entornos siempre está sirviendo tráfico de producción, mientras que el otro puede estar inactivo o usarse para probar funciones. Entonces, lo que sucede, en este caso, es que un entorno siempre contiene el código más reciente que debe estar en producción, mientras que el otro entorno contiene el código de producción más antiguo lo que hace que en caso de que necesitemos volver al código anterior podamos hacer un rollback rápidamente.
En la implementación Blue-Green, la ranura de preparación representa su implementación «verde». La ranura de producción representa su implementación «azul». Una vez que validamos que todo se ha implementado correctamente en la ranura de preparación, se realiza un intercambio entre los dos entornos. Esto hace que la implementación verde esté disponible para los usuarios finales y mueve la implementación azul a un estado inactivo donde permanece hasta que se elimine. Si surgen problemas con la nueva implementación verde, puede cambiar nuevamente para mover el azul nuevamente a producción.
Visto este concepto, nos queda saber como implementarlo. Azure nos brinda diferentes maneras de llevarlo a cabo, siendo las mas habituales usar un App Service Plan con deployment slots, o usar un conjunto de maquinas virtuales (ya sean VM o VMSS como se aprecia en la imagen siguiente) junto con un Azure Traffic Manager.
Busines central 1
Busines central 1
Green-Blue Deployment usando VMs
El método más tradicional y completo para implementar el despliegue Green Blue es el de máquinas virtuales y un Azure Traffic Manager. Azure Traffic Manager (ATM) opera en la capa de DNS para dirigir de manera rápida y eficiente las solicitudes de DNS entrantes según el método de enrutamiento que elija el usuario. Ofrece seis tipos de enrutamiento de tráfico basado en DNS: Prioridad, rendimiento, geográfico, ponderado, subred y multivalor. Para el caso que vamos a tratar, vamos a elegir el método de pesos o ponderado.
Microsoft recomienda separar en dos Grupos de Recursos los recursos que usaremos para ambos entornos. A continuación, crearemos el ATM donde asignaremos diferentes pesos a las máquinas Virtuales. Idealmente asignaremos un valor máximo a la VM azul (en la imagen, 1000) y un valor de 0 o negativo al verde. De este modo, todo el tráfico es redirigido al VM azul, quedando la maquina virtual verde en espera. Una vez hayamos subido todo el código, este probado y testeado en el entorno verde, procederemos a ir incrementando este valor y a monitorizando el funcionamiento. Este proceso de incrementar el valor de la VM verde puede automatizarse dentro del pipeline para que funcione automáticamente.
Green-Blue Deployment usando Deployment Slots
La otra manera que vamos a ver en este post para implementar este modelo es hacer uso de los Deployments Slots de App Service Plan. El hecho de disponer del nuevo código en una ranura garantiza que la aplicación en vivo nunca se interrumpa directamente y le permite validarla y tomar la decisión de implementarla o no. Los balanceadores de carga administrados de App Service se encargarán de hacer todo el trabajo por nosotros, delegando en nosotros la opción de aceptar el intercambio. Cuando se hace correctamente y la aplicación no tiene estado por diseño, la experiencia del usuario final no se ve afectada. App Service se encarga de agotar las sesiones de usuario restantes antes de completar el cambio. En circunstancias normales, este proceso no se prolonga más de 30 segundos. Cada ranura tiene todas las características y funcionalidades de su aplicación principal pero también es posible tener configuraciones específicas para cada una, de modo que afecten solo a la aplicación que se ejecuta en dicha ranura.
Debemos de tener en cuenta que no todos los planes de precios contienen esta funcionalidad, debiendo elegir los planes orientados a producción, con el coste que esto implica. El uso de estas ranuras no incrementa el precio final del plan por lo que, si disponemos de esta característica, podemos usar tantas ranuras como precisemos sin miedo a final de mes.
A continuación, procederemos a crear un App Service para alojar nuestra aplicación. Una vez creado entraremos al recurso y navegaremos a la opción de Deployment Slots, donde crearemos un nuevo slot o ranura en el botón de Add Slot. Una vez creado, podremos ver que el slot principal, marcado con la etiqueta “producción” tiene un tráfico del 100%.
Esto nos proporciona las mismas opciones que nos daba el Azure Traffic Manager con las maquinas virtuales, pudiendo cambiar el porcentaje de trafico y monitorizar el resultado, identificando rápidamente posibles errores o caídas de rendimiento y teniendo la opción de restaurar el tráfico al slot principal.
Una vez creado, es hora de irnos a nuestro devops y realizar todo lo necesario para subir nuestro código al slot correspondiente. Existen muchas maneras de realizarlo. En caso de alguna duda podéis consultar la información oficial de Microsoft en este enlace o si preferís partir de un ejemplo base podéis usar una de las plantillas que proporciona Microsoft aquí.
En este momento, tenemos el código subido, probado y testeado, pero con un 0% de tráfico. Idealmente podríamos aumentar este valor desde Azure asignándole un numero pequeño, de modo que una pequeña parte de nuestros clientes tuviera acceso a la nueva funcionalidad. Esto y una correcta monitorización nos serviría para saber si se produce o no algún problema antes del intercambio. Aquellos usuarios que entran en ese valor pequeño se denominan canarios.
También es posible realizar este cambio de slots añadiéndolo como un paso mas en el pipeline de despliegue, añadiéndolo como un paso mas de tipo Azure Cli con el siguiente comando:
Pros:
El uso de la ranuras o slots no tiene cargos adicionales
El intercambio de slots se realiza sin tiempo de inactividad
Después de la operación de intercambio, si los cambios no son los esperados, puede revertirse otra vez.
Puede asignarse un pequeño volumen de tráfico inicialmente y monitorizarlo para detectar problemas de forma precoz.
Contras:
Solo los planes de precios Estándar y Premium tienen esta característica
Al crear una ranura, no se copian todas las características y configuraciones
