Estrategia de despliegue blue-green: explicación

¿Qué es el despliegue blue-green?

El despliegue blue-green es una estrategia de implementación de aplicaciones en la que las versiones antigua y nueva se ejecutan en paralelo en dos entornos de producción idénticos. Por ejemplo, la versión anterior se ejecuta en el entorno azul, mientras que la nueva versión se prueba en el entorno verde. Una vez que terminan las pruebas, un enrutador o balanceador de carga redirige gradualmente las solicitudes al entorno verde. Luego, los desarrolladores realizan pruebas de humo antes de cambiar el tráfico de forma permanente al entorno verde.

Este enfoque usa dos entornos de producción similares (azul y verde) para lanzar actualizaciones de software.

• Entorno azul: la versión actual de producción de la aplicación

• Entorno verde: la nueva versión de la aplicación que se está probando

¿Cómo funciona el despliegue blue-green?

Así funciona el despliegue blue-green:

1. Implementar

La nueva versión de la aplicación se implementa en el entorno verde

2. Probar

La nueva versión se prueba en el entorno verde para garantizar que cumpla con todos los requisitos de rendimiento y seguridad

3. Cambiar

Cuando la nueva versión es estable, el tráfico se cambia del entorno azul al entorno verde

4. Revertir

Si se identifica algún problema, el tráfico puede volver al entorno azul

¿Cuándo es eficaz el despliegue blue-green?

El despliegue blue-green es particularmente eficaz en los siguientes escenarios:

• Ambos entornos son idénticos y están aislados.

• Debe haber un enrutador o balanceador de carga disponible.

• El sistema debe funcionar con actualizaciones continuas.

La importancia del despliegue blue-green en los procesos de DevOps

Un requisito clave para un pipeline de DevOps eficiente es implementar código para los usuarios finales de manera eficaz. La implementación continua de cambios en el código ayuda a lanzar software rápidamente, pero también puede introducir errores y vulnerabilidades que las comprobaciones automatizadas no detectan. Según la organización, la responsabilidad de implementar el código recae en los propios desarrolladores o en un equipo de operaciones que implementa artefactos de compilación desde el pipeline de CI/CD.

En ambos casos, los equipos necesitan una forma de probar rápidamente las nuevas versiones de las aplicaciones en un entorno aislado, implementarlas para los usuarios y luego volver a versiones anteriores si se detectan problemas en producción. El cambio a la nueva versión requiere una planificación cuidadosa. Los equipos de desarrollo modernos suelen adoptar la filosofía de «lanzar pronto y con frecuencia», que no es compatible con lanzamientos más complejos que requieren programar tiempos de inactividad durante los períodos de menor actividad. El cambio debe realizarse rápidamente para minimizar el tiempo de inactividad.

La idea básica de los despliegues blue-green es configurar dos entornos de producción idénticos: uno para la versión anterior y otro para las pruebas de preparación de la nueva versión. Los dos entornos pueden estar en dispositivos físicos distintos, máquinas virtuales diferentes o un entorno operativo con direcciones IP separadas para cada uno.

¿Cuáles son los beneficios de los despliegues blue-green?

• Reversiones instantáneas. El enfoque blue-green permite detectar mejor los errores gracias a que los entornos de preparación y producción son prácticamente idénticos. Si los usuarios encuentran problemas con la nueva aplicación que se ejecuta en el entorno verde, los desarrolladores pueden redirigir de inmediato las solicitudes a la versión anterior que se ejecuta en el entorno azul. Esto permite revertir los cambios al instante, sin tiempo de inactividad para los usuarios.

• Actualizaciones fluidas. Los despliegues blue-green automatizan el período entre el momento en que se «escribe» el software y su puesta en marcha en producción. En la actualización inicial, el entorno verde se usa para las pruebas y luego se convierte en el entorno de producción de la nueva versión. El entorno azul permanece activo durante un tiempo por si es necesario revertir los cambios; después se desactiva y se usa para las pruebas de preparación durante el siguiente lanzamiento.

• Sin tiempo de inactividad. En cuanto estén listos, los desarrolladores pueden pasar el código nuevo a producción durante el horario de uso habitual. No hace falta esperar a horarios de poca actividad, como la noche o los fines de semana, ni programar tiempo de inactividad. Además, el entorno de preparación puede usarse para probar la recuperación ante desastres o como respaldo.

Desventajas del despliegue blue-green

En algunos casos, el enfoque blue-green puede implicar riesgos que aumentan la probabilidad de que la implementación falle o se interrumpa.

• Sincronización de bases de datos: Administrar los cambios de esquema puede ser complicado. Con el despliegue blue-green, los cambios en las bases de datos y los datos deben sincronizarse entre los entornos azul y verde. La falta de sincronización puede provocar inconsistencias.

• Detección de fallas en QA/UAT: En infraestructuras grandes, es posible que las pruebas de QA en entornos que no son de producción no detecten ciertos errores o fallas, lo que puede ocasionar problemas que pasen inadvertidos antes del despliegue.

• Requisito de panel: Como este método implica mantener dos entornos de producción con distintas versiones del código, es esencial supervisar el estado de los paquetes y el código durante el despliegue para tener un control eficaz y activar las acciones necesarias.

• Implicaciones de costos: El despliegue blue-green requiere dos entornos paralelos, lo que prácticamente duplica los costos de operación y mantenimiento de los entornos de producción.

Despliegue blue-green y balanceo de carga de aplicaciones

Los despliegues blue-green requieren una implementación cuidadosa para minimizar el impacto en los usuarios durante el cambio. Una forma de gestionar el cambio es intercambiar los registros DNS, pero esto tiene limitaciones porque la propagación de DNS no es inmediata.

Otra opción es usar el balanceo de carga de aplicaciones para dirigir gradualmente el tráfico al entorno verde, lo que permite controlar con precisión a qué usuarios se envía. Los balanceadores de carga pueden redirigir el tráfico si hay errores en el entorno verde y se pueden programar para esperar un tiempo determinado antes de desactivar a los usuarios o terminar sus sesiones en el entorno azul.

En general, esto permite una actualización más fluida y menos interrupciones que obligar a los usuarios a cerrar sus sesiones antes de redirigir el tráfico. El balanceo de carga puede ralentizar el proceso o fallar para una pequeña cantidad de usuarios, pero la mayoría no nota tiempo de inactividad ni diferencias.

Otras estrategias de despliegue

• Despliegue blue-green: El despliegue blue-green garantiza una alta disponibilidad y permite revertir fácilmente los cambios si se detectan errores críticos. Consiste en ejecutar dos entornos paralelos, uno activo y el otro en espera, lo que minimiza el tiempo de inactividad de la aplicación.

• Despliegue A/B: Al igual que el despliegue blue-green, el despliegue A/B dirige una pequeña parte del tráfico a un servidor o entorno separado. Esta técnica suele usarse para evaluar el uso de las funciones y recopilar comentarios de los usuarios sobre una nueva versión.

• Despliegue canary: El despliegue canary lanza gradualmente nuevas funciones a un subconjunto de usuarios al asignar servidores específicos a distintos grupos. Este enfoque es útil para implementar funciones de forma incremental y recopilar comentarios durante todo el lanzamiento. Despliegue progresivo: el despliegue progresivo consiste en reemplazar secuencialmente los servidores que ejecutan la versión anterior de la aplicación por servidores que ejecutan la nueva versión. Este método facilita pausar el despliegue si es necesario.

¿En qué se diferencian los despliegues blue-green de los despliegues canary?

A diferencia de los despliegues blue-green, los despliegues canary no requieren entornos separados para las pruebas y producción. Los equipos de DevOps u operaciones implementan el cambio para un grupo pequeño de usuarios (el «canary»), prueban el lanzamiento y luego deciden si implementarlo para toda la base de usuarios.

Como no usan entornos separados, los despliegues canary solo requieren una pequeña cantidad de infraestructura adicional. Pueden configurarse con un nodo o servidor disponible, con lo necesario para admitir una pequeña parte del entorno de producción y una cantidad reducida de tráfico.

Despliegues blue-green con infraestructura como código (IAC)

Los despliegues blue-green son una técnica eficaz para lanzar software rápidamente y minimizar los riesgos tecnológicos y comerciales. También requieren tener muy en cuenta la seguridad. La arquitectura compleja de las aplicaciones y los entornos en los que se implementan, con servidores web, contenedores y microservicios, así como el uso de herramientas para automatizar compilaciones, pruebas e implementaciones en el pipeline de CI/CD, pueden provocar errores de configuración, entornos inseguros y sorpresas después del cambio.

La seguridad de las aplicaciones tradicional no basta para proteger la infraestructura IaC. Se enfoca en la aplicación después de su puesta en producción, lo que significa que los errores y las vulnerabilidades pueden afectar a los usuarios finales. Los equipos de seguridad trabajan por separado de los desarrolladores, por lo que, cuando detectan problemas, dependen del equipo de desarrollo para corregirlos. Esto crea un cuello de botella en la entrega y prioridades desalineadas entre los desarrolladores y los profesionales de seguridad. Además, la seguridad funciona como una actividad externa al proceso de desarrollo, en lugar de integrarse en el pipeline de CI/CD.

Despliegue blue-green y herramientas de IaC

Afortunadamente, existe una solución. Snyk Infrastructure as Code se integra a la perfección con el pipeline de CI/CD para proteger las configuraciones antes de que lleguen a producción. Se diseñó con un enfoque centrado en los desarrolladores y permite corregir el código automáticamente y en línea. Snyk IaC incluye pruebas automatizadas para archivos y planes de Terraform, AWS CloudFormation, configuraciones de Kubernetes y Azure Resource Manager (ARM). Los equipos de desarrollo pueden ejecutar análisis de IaC en todos los pipelines de CI/CD para detectar y corregir pronto los problemas de configuración. Las pruebas de desviación con DriftCTL también detectan los cambios en la infraestructura posteriores al despliegue, realizados por personas y herramientas ajenas al flujo habitual. Esto permite que los desarrolladores se hagan responsables de la seguridad de la compilación, las pruebas y el despliegue, y aplicar los principios de DevSecOps con herramientas de IaC para los despliegues blue-green.