Jugando con contenedores: Parte 1 - ¿Y esto a mí qué me importa?

Llevamos ya unos cuantos meses en los que es muy habitual oír hablar de microservicios, contenedores, y términos similares, asociados a las arquitecturas de nueva generación, tercera plataforma, IT de modo 2, etc. Hace poco en un foro internacional, el OpenStack Summit en Barcelona, me quedó claro que la tendencia es clara y que es un tema en el que había que ponerse las pilas.

 

Si bien es verdad que todo esto aplica a los entornos de desarrollo, a cómo construir las aplicaciones pensando de otra forma, los que proveemos de la infraestructura donde luego van a correr esas aplicaciones podemos aportar nuestro granito de arena, y un poco de conocimiento no viene mal para poder “participar”.

 

Vale, empecemos, ¿qué es un contenedor?

 

Pues un entorno de ejecución aislado para una aplicación que vive de forma temporal en un servidor y que contiene todo lo necesario para ejecutar esa aplicación de forma aislada.

 

Los que venimos del mundo Unix lo tenemos fácil, un chroot empaquetado con todos los binarios, librerías y ficheros que necesita la aplicación.

 

Hay más, pero el líder en el mercado es Docker. Parte de lo interesante es que el motor de ejecución, si bien parte de entornos Linux, está disponible en una gran cantidad de plataformas, incluyendo Windows, Mac, Linux, y cómo no, proveedores de servicio en la nube como Amazon o Azure.

 

La otra faceta muy interesante, es que hay gran cantidad de contenedores disponibles para descargar a golpe de comando, y tener disponible en minutos aplicaciones completas que luego podemos customizar.

 

No voy a escribir aquí un tutorial … si alguien quiere aprender de verdad puede empezar por aquí.

 

Un ejemplo de cómo descargar un contenedor:

 

docker1.JPG

 

Los contenedores vienen a ser una forma de virtualización simplificada, donde dejamos de instanciar máquinas virtuales con sistemas operativos completos, y pasamos a instanciar un entorno de ejecución mucho más sencillo y eficiente. En el ejemplo anterior el contenedor de MySQL ocupa 400MB, y uno con una servidor HTTP Apache no llega a 200MB.

 

En un servidor (físico o virtual) podemos tener corriendo varios contenedores de forma simultánea, y si bien pueden comunicarse entre ellos, a priori son entornos aislados, quedando algo parecido a este esquema:

 

DockerDiag1.JPG

 

Cuando descargamos un contenedor estamos descargando una serie de paquetes que terminan guardados en /var/lib/docker, y que no se modifican al ejecutar los contenedores:

 

docker2.JPG

 

Cada contenedor en ejecución utiliza un espacio temporal que de destruye cuando el contenedor se para, por lo que decimos que los contenedores utilizan almacenamiento no persistente.

 

Es posible “guardar” cambios en un contenedor mediante el comando “commit”, pero esto genera un nuevo contenedor, y está pensando para modificar la aplicación en sí, no para guardar los datos de la misma:

 

docker3.JPG

 

 

Y bien, ¿cómo guardamos los datos de los aplicaciones que corren en contenedores?

 

Para guardar los datos de forma permanente utilizamos los docker volumesaquí puedes leer más sobre este tema.

 

Esto en la práctica supone algo muy importante para nosotros los de infraestructura: con Docker las aplicaciones y los datos de las mismas están separados, por lo que se pueden aplicar políticas de protección diferentes a los mismos.

 

En lo contrario a lo que pasa por defecto en las máquinas virtuales, donde tienes una imagen, por ejemplo un fichero vmdk o vhdx,  donde tienes todo la imagen del disco de la máquina virtual, incluyendo el sistema operativo, los binarios de la aplicación y los datos de la misma. Se pueden separar, pero eso ya supone ir modificando las máquinas virtuales, y de hecho no todo el mundo lo hace, compliando en gran medida cómo realizamos copias de seguridad de los entornos virtualizados.

 

Los docker volumes pueden ser locales al servidor que ejecuta los contenedores, o puede ser un almacenamiento externo compartido. En el diagrama tenemos un ejemplo utilizando un servicio NFS para tener los datos compartidos entre varios contenedores:

 

DockerDiag3.JPG

También se puede tener almacenamiento de docker volumes mediante LUNs (iSCSI o FC), pero con la capacidad nativa de NFS para compartir ficheros entre varios servidores y usuarios, tenemos una opción muy sencilla, flexible y escalable para tener el almacenamiento para los contenedores.

 

En breve os contamos cómo utilizar un servidor NFS de los buenos para dar servicio de forma muy sencilla a Docker.

 

Saludos,

 

Jamarmu