Docker – Entregando software

Durante las próximas 3 semanas hablaremos de Docker y de cómo utilizarse para la entrega de software. Describiremos:

  • Qué es Docker
  • Cómo construir un contenedor «sencillo»
  • Cómo orquestar un sistema de contenedores completo

Cómo se hacen las cosas ahora

El desarrollo y posterior implementación/despliegue de software es un problema que todavía no ha sido resuelto.

Típicamente, un desarrollador escribe código en un entorno de trabajo personalizado, que luego será testeado en otro entorno y desplegado en producción.

Esta sucesión de procesos desde el desarrollo a salida a producción es probable (aunque no sea deseable) que se ejecuten en entornos completamente diferentes:

  • Al desarrollador le gusta usar OS X y escribe su código en Python usando la última versión en su MacBook
  • El equipo de QA utiliza Ubuntu, con la versión de Python que viene con el SO, ejecutado en máquinas virtuales
  • El equipo de operaciones despliega el código en un clúster de servidores dedicado donde corre Redhat Enterprise Linux

Las diferencias de hardware, sistema operativo o librerías pueden producir problemas en el entorno de QA o producción que no se da en desarrollo.

Imagina el siguiente entorno de producción:

Production environment

Tenemos un único balanceador de carga que conecta dos servidores de aplicaciones que, por turnos, usan un servidor de caché compartido, un servidor de bases de datos y un servidor de ficheros. Dejando de lado el único punto de fallo del nivel más bajo, tenemos la posibilidad de escalar bajo demanda la capa de aplicación.

Lo que el diagrama no muestra es que, a lo largo del tiempo, la capa de aplicación ha cambiado de ser un portal que utiliza servicios web escritos en Python a tener lo mismo pero con unos nuevos servicios web escritos en Node.js y Ruby.

En un entorno de desarrollo la arquitectura es mucho más simple, ya que los componentes arriba descritos corren en la misma máquina.

Mientras que esto reduce la complejidad para los desarrolladores, el proceso de despliegue del sistema en el entorno de test y de producción necesitan adaptarse.

Tal como está, cambios en el código de Ruby, suponen cambios en Python.

Lo mismo ocurre para los cambios en la interfaz gráfica del portal.

Con esta configuración, las actualizaciones de componentes individuales no han sido implementados de forma que requieran que actualicemos por completo la capa de aplicación por cualquier cambio menor.

El problema que intentamos resolver

Idealmente nos gustaría tener un método que replicase un completo y complejo sistema con una variedad de plataformas hardware y entornos con la posibilidad de actualizar componentes en lugar del sistema completo para cada cambio.

Docker llama a esto «la matriz del infierno»:

The matrix from hell

Necesitamos una manera de entregar actualizaciones desde los sistemas de desarrollado a cualquier número de entornos de misión crítica.

Una analogía para la entrega o despliegue de software podría ser un proveedor de bienes que envía un producto físico a un cliente.

Imagina que vendes un producto físico y tienes clientes en tu mismo continente así como fuera de él.

Los requisitos para la entrega de dicho producto depende del tamaño, embalaje y sistema de transporte.

En algunos casos, estos requisitos puede variar de un país a otro.

Así que para transportar bienes tenemos una «matriz del infierno» parecida a la que tenemos en nuestros centros de datos:

Also a matrix from hell

Necesitas saber cómo va a ser transportado tu producto en cada etapa, la ruta que va a seguir, asegurando que el embalaje será adecuado para la entrega de tus bienes en el destino final.

Antes de los 60, esta era la situación hasta que el contenedor fuese inventado.

Cada contenedor es diseñado como una unidad estandarizada que permite que los bienes fuesen cargados en una caja que se sellaba y permanecía sellada hasta su entrega.

Mientras tanto, podía ser cargada y descargada, apilada y movida con eficiencia a lo largo de grandes distancias y transferida de un método de transporte a otro.

Cómo Docker nos ayuda

Docker usar funcionalidad del núcleo de Linux para permitir el empaquetado de software en contenedores que puede correr juntos en la misma máquina, asegurado el aislamiento de los recursos y eliminando la necesidad de máquinas virtuales pesadas.

Podemos ver la diferencia entre las dos configuraciones en el siguiente diagrama:

Diagram docker

En un entorno de máquinas virtuales tenemos máquinas individuales donde corre un SO completo, con las librerías necesarias y el software que ejecuta las aplicaciones.

Con Docker, el “SO invitado” se convierte en el “Hypervisor”, cada contenedor comparte recursos con el OS anfitrión, en particular, el núcleo de Linux.

Este último punto es importante, ya que permite usar contenedores que usen distintos sistemas operativos, proporcionando gran flexibilidad.

Así que podríamos tener un Ubuntu con SO anfitrión que contuviese contenedores donde corrieses CentOS, Debian o Redhat Linux.

Desplegar código desde desarrollo a producción se hace usando contenedores que encapsulan la funcionalidad completa sin que su contenido requiera ningún cambio en alguna etapa intermedia.

changes at any intermediate stage

Convirtiendo la «matriz del infierno» en:

Base Matrix

Así, aseguramos que el código que el desarrollador escribió es lo que acaba en producción después de haber la validación de QA.

Docker en Solid Gear

En Solid Gear usamos Docker de diferentes maneras:

  • En el desarrollo de nuevas aplicaciones
  • En entornos de testeo bajo demanda
  • Convertir aplicaciones ya existentes

Desarrollo de nuevas aplicaciones

Seguramente la forma más sencilla de usar Docker en un proyecto es desde el principio.

Somos capaces de alinear la arquitectura con cómo las cosas se harán con Docker.

Tenemos un proyecto con una aplicación completa que está compuesta de 4 contenedores, con un quinto que actúa como frontend (compartido con más contenedores).

Los cambios en la aplicación sólo necesitan actualizaciones en el contenedor de la aplicación, sin que los otros 3 tengan que ser modificados.

Veremos cómo hacer esto en otro artículo.

Entornos de testeo bajo demanda

Los contenedores de Docker son muy ligeros y apenas necesitan tiempo para levantarse.

En otro de nuestro proyectos hemos diseñado e implementado un entorno completo que permite a los ingenieros de QA seleccionar desde un menú:

  • Software para el servidor web
  • Versión de PHP
  • Software de BD
  • Versión de la aplicación

Estas opciones son luego usadas para elegir un contenedor pre-construido que en cuestión de segundos está corriendo. Imagina la cantidad de recursos y tiempo necesarios para replicar esto usando hardware físico o virtual. Una vez que el ingeniero QA deja de usar el entorno, éste puede ser borrado.

Convertir aplicaciones ya existentes

Donde Docker no es fácil de implementar es en la conversión de aplicaciones existentes en un modelo multi-servidor como el descrito anteriormente.

Con una compañía, actualmente estamos investigando la posibilidad de usar Docker en un sistema en el cual la capa de aplicación está formada por múltiples componentes que son candidatos a ser convertidos en contenedores individuales.

Una vez convertida la plataforma en contenedores, trabajaremos tanto con los desarrolladores como con los ingenieros de QA para usar Docker en el desarrollo y testeo.

Esta configuración les permitirá trabajar de una manera consistente y en entornos limpios que podrán ser desplegados en producción a lo largo del tiempo.

 

Otros enlaces relacionados:

Desplegando un registro de Docker privado y seguro

Docker II – Construyendo un contenedor

Deja un comentario

¿Necesitas una estimación?

Calcula ahora

Centro de preferencias de privacidad

Cookies propias

__unam, gdpr 1P_JAR, DV, NID, _icl_current_language

Cookies de analítica

Estas cookies nos ayudan a comprender cómo los usuarios interactúan con nuestra página web.

_ga, _gat_UA-42883984-1, _gid, _hjIncludedInSample,

Cookies de suscripción

Estas cookies se utilizan para ejecutar funciones de la Web, como no mostrar el banner publicitario y / o recordar la configuración del usuario dentro de la sesión.

tl_3832_3832_2 tl_5886_5886_12 tve_leads_unique

Otra