Implementación sin tiempo de inactividad: actualice su aplicación dockerizada con la técnica azul-verde

En un artículo que escribí hace un mes, hablé sobre cómo implementar continuamente su aplicación web de Python en un entorno de producción (o pre-desarrollo/escenario).

Recientemente me encargaron crear un microservicio (usando Python y FastAPI) para hacer coincidir dos voces y dar un puntaje de predicción si ambas coincidían o no. Las partes interesadas habían solicitado una función de desbloqueo de voz.

Tuvimos una reunión de ingeniería y me puse de pie para asumir la tarea (o mi líder me defendió, jaja).

Fue una tarea interesante, ya que nunca antes había trabajado (entrenado o lo que sea) con un modelo ML. Me llevó una semana diseñar, compilar y enviar el código a una instancia de AWS EC2. Soy un gran admirador de CI/CD, así que usé lo que me resultaba más cómodo: GitHub Actions.

Una semana después... Se solicitaron cambios y quería probar una nueva técnica [de implementación] que había estado investigando. Necesitaba que la aplicación de microservicio dockerizada se ejecutara correctamente en la instancia EC2 de AWS para no experimentar ningún tiempo de inactividad cuando volviera a implementar.

Y tenía el truco perfecto bajo la manga.

Ese truco es: la técnica azul-verde .

Según el documento técnico de AWS sobre implementaciones azules/verdes, se trata de una estrategia de implementación en la que se crean dos entornos separados pero idénticos.

Un entorno (azul) ejecuta la versión actual de la aplicación y un entorno (verde) ejecuta la nueva versión de la aplicación. El uso de una estrategia de implementación azul/verde aumenta la disponibilidad de la aplicación y reduce el riesgo de implementación al simplificar el proceso de reversión si falla una implementación.

Una vez que se han completado las pruebas en el entorno verde, el tráfico de aplicaciones en vivo se dirige al entorno verde y el entorno azul queda obsoleto.

En términos simples, la técnica de implementación azul/verde es una forma de reducir el tiempo de inactividad y el riesgo mediante la ejecución de dos entornos de producción idénticos.

Si es la primera vez que escucha una técnica de implementación de este tipo, no hay absolutamente nada que temer, le proporcionaré pasos detallados que lo ayudarán a lograr una implementación azul-verde.

Vayamos directamente a los pasos:

1. Comience por crear una nueva imagen de Docker con su código actualizado y etiquétela con un nuevo número de versión.

   
   

 $ docker build -t myexample:v2 .

Esto creará una nueva imagen de Docker con la etiqueta myexample:v2 utilizando el Dockerfile en el directorio actual.

Donde myexample:v2 es el nombre de la imagen acoplable recién creada. En mi caso, era el nombre del proyecto ML. Por ejemplo, docker build -t companyx-servicename-backend:v2

2. Inicie un nuevo contenedor de Docker a partir de la nueva imagen, pero no lo exponga al mundo exterior todavía.

   
   

 $ docker run -d --name myexample-v2 myexample:v2

Esto iniciará un nuevo contenedor Docker con el nombre myexample-v2 de la imagen myexample:v2 .

3. Espere a que el nuevo contenedor se inicie e inicialice, asegurándose de que funcione correctamente.

   
   

 $ docker logs myexample-v2

Use el comando docker logs para verificar los registros del nuevo contenedor y asegurarse de que se haya iniciado e inicializado correctamente.

4. Utilice un proxy inverso, como NGINX, para enrutar el tráfico tanto a los contenedores antiguos como a los nuevos. Configure su proxy inverso para escuchar las solicitudes y reenviarlas tanto a los contenedores antiguos como a los nuevos. Esto le permitirá cambiar gradualmente el tráfico al nuevo contenedor.

Este es un ejemplo de una configuración de NGINX que enruta dos contenedores:

 upstream myexample { server myexample-v1:8000; server myexample-v2:8000 backup; } server { listen 80; server_name myexample.com; location / { proxy_pass http://myexample; } }

Esta configuración configura un grupo ascendente llamado myexample con dos servidores: myexample-v1 y myexample-v2 . La palabra clave backup se utiliza para marcar el segundo servidor como copia de seguridad. La directiva proxy_pass se utiliza para reenviar solicitudes al grupo upstream myexample .

Asegúrese de actualizar la configuración del proxy inverso para reflejar el nombre y el puerto de su aplicación.

5. Cambie gradualmente el tráfico del contenedor antiguo al contenedor nuevo ajustando la configuración del proxy inverso.

   
   

Para cambiar el tráfico al nuevo contenedor, ajuste la configuración del proxy inverso para dar más peso al nuevo contenedor. Esto se puede hacer eliminando la palabra clave de copia de seguridad de la directiva del servidor:

 upstream myexample { server myexample-v1:8000; server myexample-v2:8000; } server { listen 80; server_name myexample.com; location / { proxy_pass http://myexample; } }

Esto hará que NGINX envíe más solicitudes al contenedor myexample-v2 . Supervise su aplicación y ajuste la configuración según sea necesario hasta que todo el tráfico fluya hacia el nuevo contenedor.

6. Una vez que todo el tráfico fluya hacia el nuevo contenedor, puede detener y retirar el antiguo contenedor de manera segura.

   
   

 $ docker stop myexample-v1 $ docker rm myexample-v1

Esto detendrá y eliminará el contenedor anterior, liberando recursos en el servidor.

Conclusión

Soy nuevo en esta técnica y, obviamente, no sé mucho al respecto. Pero voy a seguir aprendiendo sobre sus ventajas y desventajas y otras técnicas que funcionarán mejor. ¿Tienes un truco o dos bajo la manga que te gustaría compartir conmigo?

te lo agradeceré Déjame tenerlo (en la sección de comentarios).

ay ay No olvides suscribirte a mi aburrido boletín. He aprendido muchas cosas desde el primer trimestre y las compartiré pronto. Chao.