Introducción a Docker
Docker como alternativa ligera a la virtualización
Durante la primera edición del presente libro, Docker era una herramienta todavía joven, alrededor de la que se podía percibir una pasión real. Como sucede habitualmente en estos casos, existía cierta confusión sobre el alcance exacto de la tecnología, y el libro tenía como objetivo no comenzar directamente con una explicación de las funcionalidades de Docker, sino concretar la intención de la herramienta, es decir, el papel que se proponía jugar en un SI (Sistema Informático).
Unos dos años más tarde, y aunque Docker todavía era una herramienta importante pero casi estándar entre las posibilidades que se ofrecían para desplegar aplicaciones, esta necesidad de entender el por qué de la tecnología antes de adentrarse en el cómo, sigue estando de actualidad. Docker se interesa por todo; se beneficia de un rico ecosistema, ha sido adoptado por todos los proveedores de cloud y dispone de una implementación Windows además de su origen Linux, pero volver a los fundamentos y comprender por qué nació Docker, permite entender mejor su funcionamiento.
Los capítulos que siguen usarán únicamente Docker en su versión Linux. Aunque existe una versión para Windows 10 y Windows Server 2016, los comandos y conceptos mostrados en el presente libro son exactamente los mismos, por lo que nos quedamos con la versión original para este libro sobre los fundamentos.
1. El enfoque por virtualización
En una visión global, Docker idealmente se describe como un conjunto de herramientas que facilitan la implantación de despliegues informáticos, como si fuera una virtualización ligera, aunque no sea propiamente dicho una técnica de virtualización. Con el objetivo de precisar en qué consiste esta ligereza, a continuación se muestra un primer esquema de una arquitectura virtual tradicional, tal y como la encontraríamos en herramientas como VMware, VirtualBox o Hyper-V.
El tamaño de los bloques simboliza el espacio ocupado por los diferentes componentes, pero las proporciones no muestran completamente la enorme cantidad de espacio que necesita un sistema operativo (OS, para Operating System). En ese caso, el esquema sería legible...
Principio de los contenedores
El aporte principal de Docker consiste, como se ha explicado en la sección anterior, en una reducción drástica de los recursos utilizados, conservando una estanqueidad entre las aplicaciones. Pero, una vez más, las tecnologías de compartimentación de memoria existían antes de Docker. Este último ha añadido un determinado número de funcionalidades adicionales, que han permitido su adopción más amplia.
En el primer grupo de estas funcionalidades, se encuentra la normalización de los contenedores: Docker ha tenido éxito allí donde los enfoques puramente técnicos se han detenido, porque ha hecho extremadamente sencilla la recuperación de contenedores existentes y su creación, usando métodos estándares. En la historia de la informática, la normalización y la estandarización, casi siempre han sido requisitos previos para la difusión amplia de una tecnología dada.
El API Docker se ha estandarizado por medio de dos especificaciones de Open Container Initiative, un consorcio web abierto de normalización de la gestión de contenedores al que se adhiere Docker, así como numerosas grandes empresas de informática. La primera de estas especificaciones afecta a la gestión de la ejecución de los contenedores (y por tanto al API para arrancarlas, detenerlas, etc.) y la segunda, la definición de las imágenes. Hay más información en https://www.opencontainers.org/.
Un API (de Application Programming Interface), es un conjunto de funciones que permiten controlar una funcionalidad informática...
Los aspectos principales de Docker
Como se ha explicado más atrás, Docker se basa en los fundamentos existentes y alcanza un determinado éxito porque convierte en sencillo el uso de estas tecnologías subyacentes. Sin entrar en detalles (Docker tiene por objetivo justamente ocultar este mecanismo complejo), siempre conviene echar un vistazo más profundo para entender mejor el funcionamiento de la máquina Docker.
1. Espacio de nombres
En la base de la tecnología de contenedores, se encuentra la noción de espacio de nombres. Estos "espacios de nomenclatura" permiten crear conjuntos de recursos gestionados por Linux, mientras que de manera tradicional se gestionaban en un único bloque. Por ejemplo, los procesos se identifican por un número, accesible en una lista de todos los procesos ejecutados por el sistema Linux. Se trata del identificador de proceso o PID.
Fuera de los espacios de nombres, el comando ps envía la lista completa de los procesos activos en la máquina Linux. El principio del espacio de nombres es realizar las visualizaciones restringidas de estos recursos, según otra lógica. Por ejemplo, en el espacio de nombres 1 solo es visible el proceso de PID 10, y aparece bajo un valor de PID local de 3. En un segundo espacio de nombres, son visibles los procesos 11 y 12 pero con los identificadores 3 y 4.
De esta manera, allí donde el nodo Linux impide tener el mismo identificador para dos procesos separados es posible, con la condición de estar en dos espacios de nombres diferentes, tener dos veces el mismo PID. De una determinada manera, se puede decir que el identificador del proceso es, espacio de nombres1.pid3. En este caso, los espacios de nombres funcionan un poco como los espacios de nomenclatura de las clases en los lenguajes orientados a objetos, como Java o C#.
Además, cuando el usuario del sistema se localiza en un espacio de nombres dado, utilizando el comando ps solo ve los procesos asociados a este espacio de nombres. Está aislado del resto de procesos gestionados por el nodo Linux.
Esta es la capacidad que se corresponde con prefijar los identificadores que se implementa por los espacios de nombres en el nodo Linux. El ejemplo dado para los procesos, se puede aplicar al resto de recursos que soporten la partición por esta tecnología. En efecto, existen espacios de nomenclatura para los procesos...
Aspectos adicionales de Docker
La lista de los fundamentos tecnológicos sobre los que se basa Docker es, como se ha visto en las páginas anteriores, particularmente amplia. Esto no significa que Docker se contente con agrupar módulos existentes.
En particular, Docker no es un nuevo LXC: se ubica por encima de la gestión de contenedores para simplificarla y, de esta manera, realizar una verdadera virtualización de aplicaciones. Aquí se trata de una fuerte apuesta, que se traduce en la restricción de situar una única aplicación en un contenedor.
Por supuesto, esto presenta límites porque por ejemplo, las aplicaciones que necesitan tareas desencadenadas regularmente por un proceso cron, no se podrán desplegar en Docker sin modificaciones. Pero esta también es la razón por la que Docker ha tenido éxito allá donde LXC no tuvo el éxito masivo esperado: el enfoque "un contenedor - una aplicación" se basa en una simplificación que ha hecho que para muchos usuarios más sea abordable este enfoque de los contenedores Linux.
En teoría, Docker no impide realmente que varios procesos funcionen al mismo tiempo en el mismo contenedor pero en la práctica, las herramientas se hacen de manera que es difícil proceder de otra manera. Hay enfoques que permiten eludir esto (en particular se detallará supervisor), pero contravienen...
El ecosistema Docker
En una arquitectura virtualizada como VMware o Hyper-V, el hipervisor es central, pero tendría una utilidad finalmente reducida sin la virtualización de las redes, el administrador de máquinas virtuales, las herramientas de movimiento en caliente de máquinas, los API de operación y los clientes asociados, etc.
Sucede lo mismo con Docker, que no se usa solo. Respecto a su función central de gestión del ciclo de vida de los contenedores, es la herramienta más vista, pero no muestra todo su potencial excepto si se une a un ecosistema cada vez más nutrido.
Antes de todo, Docker es múltiple y se compone en sí mismo por un cliente, un API y de un servidor en forma de demonio. Pero la funcionalidad de almacén central realizado por Docker Hub, también es principal: un almacén público, accesible con una sencilla conexión a Internet, permite favorecer la reutilización de las imágenes ya preparadas. Esta es una de las razones principales de la velocidad de adopción excepcional de Docker.
Desde el inicio, Docker ha sido capaz de integrar tecnologías desarrolladas de manera externa inicialmente, para ofrecer funcionalidades adicionales necesarias para su integridad.
De esta manera, la herramienta Fig rápidamente se convirtió en Docker Compose y ha pasado por varias versiones desde entonces. Automatiza la implantación...
Arquitecturas de servicios
Todas las secciones anteriores de este capítulo de introducción, sirven para colocar Docker en el paisaje informático, explicar en qué se basa, su modo de funcionamiento y su ecosistema. En esta sección se plantea la pregunta del por qué. ¿Para qué sirve finalmente Docker? Porque esta capacidad de ahorrar recursos, poner en común las capas y sellar los contenedores ligeros, ¿es realmente importante en la práctica? En pocas palabras, ¿cuál es la necesidad práctica importante que ha hecho que Docker sea imprescindible?
Hay numerosas razones para la explosión del uso de Docker en estos últimos años, pero la mayor parte de estas razones se agrupan alrededor del hecho de que al final, favorecen la aparición de arquitecturas de servicios.
1. Histórico de las arquitecturas de servicios
a. Aspectos principales
La mayor complejidad cada vez de los SI, ha sacado a la luz dos principios fundamentales.
El primero es que el valor de un SI reside más en sus interacciones que en sus aplicaciones. Una aplicación de caja registradora no sirve para mucho, si no está relacionada con la contabilidad. El interés de una aplicación de gestión de pagos se ve limitado de manera importante, si no puede enviar solicitudes de transferencias bancarias. Un software de diseño asistido por ordenador no está correctamente adaptado si no se puede asociar a las líneas de producción basadas en máquinas controladas digitalmente.
El segundo principio - que no está relacionado con la informática - es que es importante dividir para ganar. A partir de una determinada complejidad, no es realista querer gestionar un sistema con una única aplicación y la especialización implica obligatoriamente una división de las responsabilidades.
El caballo de batalla de la arquitectura de los SI, ha sido empujar este segundo principio al máximo con diferentes enfoques, durante los últimos veinte o treinta años que han conocido más o menos éxito. No mencionaremos los primeros métodos artesanales de intercambio de datos directamente a nivel de los Sistemas de Gestión de Base de Datos con, en sus últimas evoluciones, la implantación de ETL (Extract Transform Load). Se trataba...