&
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
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.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Gracias
Ignacio L Flores