&

Zero downtime deployment

Sobre mi

Ignacio López Flores

Founder & CEO @ Introbay

@ignaciolflores

IRC: ignaciolflores

¿Por qué?

Docker es una tecnología ampliamente extendida, pero aún queda mucho por desarrollar y documentar.

¿Por qué?

En concreto, hay poca información relacionando Drupal & Docker.

¿Por qué?

Los procesos de actualización suelen ser el punto crítico en el ciclo de vida de una aplicación.

¿Por qué?

En general, hablando de DevOps & Drupal hay poca información.

¿Por qué?

Porque hablar es gratis ;-)

Actualizaciones

  • Base de datos: Si tenemos una actualización que implica modificaciones en la base de datos, como mucho podremos minimizar el downtime.
    Dos opciones:
    • Usuarios conocidos: Podemos avisar a los usuarios y planificar la actualización, incluso usar horas a las que se sepa que no habrá usuarios conectados.
    • Usuarios registrados: No podemos avisar a los usuarios => Evaluar el impacto para planificar mejor momento... te toca trasnochar

Actualizaciones

  • Otros cambios: En cambio, si las modificaciones son de estilo o en un tpl, preprocess, código de un módulo, etc. podremos conseguir desplegar sin tiempo de caída.

Opciones para desplegar

  • Re-deploy
  • Blue-Green deployment
  • A/B deployment

Re-deploy

Destroy, Create => Downtime

Blue-Green

Solucionamos el problema asegurando que hay al menos dos servicios/entornos en ejecución al mismo tiempo.

Perooo, y cómo se hace??

Un entorno se encuentra en estado idle y otro en live.

Comenzamos a escalar el idle y a eliminar el live hasta que se invierta la situación

Perooo, y cómo se hace??

docker-compose scale es tu amigo.

Mi amiga la caché

La caché se limpia una vez hecho el paso de blue a green.

Rollback

Volver atrás es tan sencillo como deshacer el cambio y volver a blue.

Evolución

Una vez hemos pasado de blue=>green, la siguiente actualización será green=>blue

En nuestro docker-compose.yml aumentamos la versión de blue y hacemos la magia con scale.

Varias opciones para balancear el tráfico

  • DNS: muy potente pero tarda en propagar los cambios.
  • Proxy: modificamos la configuración del balanceador usando variables de entorno.
  • Híbrido: DNS y luego LB => geoenrutamiento, basado en latencia, etc.

A/B deployments

Amazon y Google usan esta técnica

Múltiples instancias de cada una de las versiones

Cuando la confianza en una nueva versión va aumentando, se va sustituyendo la anterior

Links de interés

A tener en cuenta...

Varios sistemas que hacen cosas parecidas.

Docker cloud, Rancher,...

A tener en cuenta...

Cuidado con el hype.

No sobrecargues tus sistemas con cosas que no te hacen falta.

¿Preguntas?

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Gracias

Ignacio L Flores