Actualizar en producción sin pérdida de servicio

Viejo problema: actualizar en producción es downtime

Este artículo trata de no perder ni un segundo de servicio cuando se actualiza una web, una aplicación o un portal. Es un viejo problema que todas las empresas y todos los proyectos sufren; reemplazar o actualizar la versión de la aplicación en producción requiere un tiempo de actualización, copia y puesta en servicio de la nueva versión. Sin hablar de las vueltas atrás si algo no ha salido tal como debiera.

Para los que no son técnicos me refiero a esas páginas de “estamos en obras”, “vuelve en 5 minutos” o “Ups! It’s embarrassing …”.

Es un clásico,  pero en Ackstorm creemos que no está justificado, no en el 2016 en plena era Cloud donde caídas demasiado largas, inestabilidad frecuentes en títulos, tags y descriptores afectan negativamente al posicionamiento en buscadores y la percepción en nuestros clientes.

Nueva solución: Dockers

Si hablamos de desarrollo, no todo el mundo cuenta con los tres entornos recomendados para el correcto testeo y puesta en producción de aplicativos y software, me refiero a tener entornos con versiones en desarrollo, en pre-producción o staging y producción.

Y justamente intentar facilitar estas plataformas es lo que Docker intenta solucionar. La tecnología de contenedores con Docker es la que voy a utilizar para solucionar este problema en mis servidores en Internet.

Docker ha cambiado el negocio del hosting y la virtualización en general, de hecho ha reescrito el “cómo” se trabaja en los departamentos de Desarrollo y Sistemas.

Docker es una máquina virtual sin máquina virtual, una isolación de mi aplicación con sus librerías y datos. Una agrupación de directorios y archivos gestionados en sí como si de código se tratara, con sus actualizaciones, sus modificaciones y sus commits.

Ese mismo contenedor sirve para desarrollo y testeo y producción. Esto es, si funciona en el pc de mi desarrollador funcionará en producción.

El método correcto: Blue Green Deployment

El mejor método para actualizar un aplicativo en producción es el llamado Blue/green deployment. Partimos de una situación azul inicial, la manera más fácil de cambiar una aplicación es mantener dos versiones  coexistiendo un tiempo para eliminar la vieja después.

Es sencillo en apariencia pero esto requiere que la infraestructura y los servidores de aplicaciones permitan tener dos aplicaciones balanceadas en un mismo momento. Esto, en sistemas on-premise o en máquinas virtuales no es trivial, pues requiere de elementos externos como balanceadores y routers y configuraciones manuales de los endpoints o dispositivos implicados y además es vulnerable al error humano.

La facilidad de ejecución de diferentes Docker en el mismo servidor es la clave para poder hacer un cambio de versiones sin pérdida de servicio.

Podemos lanzar una aplicación simplemente desde un repositorio de Docker. Nada nos limita para poder lanzar un contenedor con diferentes versiones de mi aplicación y un balanceador que gestione las conexiones entre ellas.

En la imagen siguiente podemos ver dos versiones de Nginx, y un balanceador HaProxy delante. Podemos lanzar una segunda versión de mi aplicación de manera transparente. Pero todo es virtual, todo es efímero, todo es automático.

En la imagen en un mismo servidor dos instancias Nginx Dockerizados de diferentes versiones trabajando de manera balanceada mediante un Docker HaProxy. Podemos balancear, eliminar un Nginx y todo seguirá funcionando. Sin añadir más ni servidores ni elementos de control de red. Sin pérdida de servicio.

Artículo redactado por Javier Domingo, Senior Cloud Arquitect en Ackstorm