El ecosistema Docker: las Docker tools más populares

Desde el lanzamiento de la versión v1.12, Docker también está disponible para los últimos ordenadores macOs y Windows como aplicación nativa de escritorio, pero los usuarios de sistemas anteriores han de recurrir a la Docker Toolbox para poder instalar la plataforma de contenedores.

La Toolbox de Docker consiste en un instalador (installer) que automatiza la configuración de un entorno Docker en los sistemas Windows y macOS anteriores. El software contiene los siguientes componentes:

• Docker Engine

• Docker Machine

• Docker Compose

• Orable VirtualBox

• GUI de Docker Kitematic

• Interfaz de líneas de comando configurada para Docker

El núcleo de la Docker Toolbox está compuesto por el software de código abierto Kitematic. Este se integra en la máquina Docker para desplegar una máquina virtual basada en la Oracle VirtualBox, con la que se puede instalar la plataforma de contenedores en Windows y Mac. Para trabajar con Docker, el usuario dispone de una interfaz gráfica en la cual puede crear, arrancar e interrumpir contenedores a golpe de clic. Una interfaz a Docker Hub permite explorar el repositorio y descargar imágenes fácilmente desde la aplicación de escritorio.

Además de la GUI, también se dispone de una interfaz de líneas de comando predefinida en la cual se registra cualquier cambio realizado con la interfaz gráfica. De esta forma el usuario puede alternar una y otra para ejecutar y dirigir los contenedores. Kitematic también contiene funciones para asignar puertos automáticamente, definir variables de entorno y configurar unidades de disco (volumes).

Si bien en la documentación la Docker Toolbox está marcada como obsoleta (“legacy”), el software se sigue soportando, aunque el equipo de desarrollo recomienda utilizar las aplicaciones nativas para escritorio Docker for Windows o Docker for Mac, siempre y cuando se cumplan los requisitos de sistema.

Sumándose a estos programas desarrollados por Docker Inc., algunos proveedores externos también se han animado a desarrollar herramientas y plataformas que o bien se pueden conectar con el Docker Engine o bien se han desarrollado exclusivamente para la popular plataforma. Entre la diversidad de proyectos de código abierto englobados dentro del ecosistema de Docker se cuentan la herramienta de orquestación Kubernetes, el sistema de gestión de clústeres Shipyard, la solución de despliegue de aplicaciones multicontenedor Panamax, la plataforma de integración continua Drone, el sistema operativo en la nube OpenStack y el sistema operativo de centros de datos Mesosphere DC/OS, basado en el gestor de clústeres Mesos.

Hubo un tiempo en el que Docker no podía suministrar herramientas propias de orquestación como Swarm y Compose. Es por eso que, desde hace años, numerosas empresas invierten en el desarrollo de herramientas a medida para facilitar el funcionamiento de la plataforma de contenedores en infraestructuras grandes y distribuidas. Entre las soluciones más conocidas de este tipo se encuentran, además de Helio, la plataforma libre de orquestación de la casa Spotify, el proyecto open source Kubernetes.

Kubernetes es un gestor de clústeres para aplicaciones contenerizadas desarrollado en su mayor parte por Google y hoy bajo el patrocinio de la Cloud Native Computing Foundation (CNCF).

Shipyard es una solución de gestión desarrollada por la comunidad de usuarios de Docker basada en Swarm y que permite a los usuarios gestionar recursos de la plataforma como contenedores, imágenes, hosts y repositorios privados a través de una interfaz gráfica de usuario. Shipyard está disponible como aplicación web, con lo que se diferencia de la aplicación de escritorio Kitematic.

El programa es completamente compatible con la Remote API de Docker y utiliza la base de datos NoSQL de código abierto RethinkDB para guardar las cuentas de usuario, las direcciones y los eventos. Además de proveer funciones de gestión de clústeres en una interfaz web central, la herramienta también incluye una función de verificación de usuarios y una de control del acceso basado en roles.

El software está basado en el toolkit de gestión de clústeres Citadel y se compone en lo esencial de tres elementos: Controller, API y UI.

• Shipyard Controller: este componente constituye el corazón de Shypyard. El controlador interactúa con la base de datos RethinkDB para almacenar la información y permite la comunicación con los hosts en un clúster de Docker y controlar los eventos.

• Shipyard API: la API de Shipyard está basada en REST. Todas las funciones de la herramienta de gestión se controlan con ella.

• Shipyard User Interface (UI): la interfaz de usuario de Shipyard es una aplicación AngularJS que provee a los usuarios de una interfaz gráfica para gestionar los clústeres de Docker en el navegador. Todas las interacciones en la interfaz de usuario tienen lugar a través de la API de Shipyard.

En la página oficial de Shipyard puedes conocer a fondo a este proyecto de código.

Los desarrolladores del software de código abierto Panamax se han propuesto simplificar el despliegue de aplicaciones multicontenedor. La herramienta ofrece a los usuarios una interfaz gráfica con la cual se pueden desarrollar, desplegar y distribuir aplicaciones complejas basadas en contenedores Docker sencillamente por drag and drop.

Panamax permite guardar estas aplicaciones en la forma de plantillas de aplicación y repartirlas en estructuras clúster muy fácilmente. A través de un App Marketplace integrado en la herramienta y alojado en GitHub, estas plantillas se pueden guardar y publicar en repositorios Git. La siguiente animación ilustra la mecánica de Panamax y muestra sus ventajas:

Drone está integrado en Docker y soporta diversos lenguajes de programación como PHP, Node.js, Ruby, Go o Python. La única dependencia necesaria es precisamente la plataforma de contenedores. Esto quiere decir que para crear una plataforma de integración continua con Drone es necesario hacerlo en un sistema en el cual esté instalado Docker.

Drone soporta diversos repositorios de control de versiones. En la documentación del proyecto se encuentra un manual con el nombre de readme.drone.io para la instalación estándar con integración de GitHub.

Para administrar la plataforma de CI se utiliza una interfaz web a través de la cual se cargan los builds de software desde cualquier repositorio Git, se agrupan aplicaciones y se ejecuta el resultado en un entorno de pruebas previamente definido. Para ello, por cada prueba se define un archivo .drone.yml en el cual se fija cómo se ha de crear y ejecutar la aplicación.

En el vídeo a continuación, Brad Rydzewski, integrante del equipo de desarrolladores de Drone, presenta la plataforma libre de integración continua:

Según los desarrolladores de la plataforma, con Drone los usuarios disponen de una solución de CI de código abierto que aúna las ventajas de productos alternativos como Travis y Jenkins en una aplicación sencilla y amigable.

Además de los seis componentes principales mencionados, la arquitectura de OpenStack se puede ampliar con diversos módulos opcionales:

• Horizon (panel de control): el panel de control de OpenStack recibe el alias de “Horizon” y ofrece una interfaz gráfica de usuario basada en la web por medio de la cual se pueden gestionar otros componentes como Nova o Neutron.

• Heat (orquestación): este módulo opcional provee un servicio que permite orquestar con plantillas aplicaciones en la nube compuestas por varios elementos. Heat suministra para ello una API REST nativa y el formato de plantilla HOT, aunque también soporta el formato de plantilla AWS CloudFormation, así como una API Query.

• Ceilometer (servicio de telemetría): con este módulo, OpenStack dispone de un servicio central de telemetría con el cual se pueden compilar datos estadísticos en un contexto de facturación o evaluación comparativa (benchmarking).

• Trove (Database as a service): con este componente se pueden suministrar bases de datos relacionales y no relacionales.

• Zaqar (mensajería): antes llamado Marconi, este módulo opcional amplía a OpenStack con un servicio de mensajería en la nube multi-tenant para desarrolladores web. El software ofrece una API REST con la cual los programadores pueden enviar mensajes entre diferentes componentes de una aplicación Saas o Mobile.

• Designate (servicio de DNS): este componente provee de DNS as a Service a OpenStack. La gestión de los registros de dominio tiene lugar con una API REST. El modulo soporta varios mandantes (multi-tenant) y utiliza funciones de verificación gracias a la integración de Keystone.

• Barbican (gestión de claves): este módulo ofrece una API REST con la cual almacenar de forma segura, administrar y suministrar contraseñas, claves y certificados.

• Sahara (Elastic Map Reduce): este componente opcional permite crear y gestionar clústeres Hadoop basados en OpenStack.

• Ironic (Bare Metal Treiber): este módulo adicional es una ramificación del driver baremetal de Nova y ofrece a los usuarios de OpenStack la posibilidad de desplegar máquinas Bare Metal en lugar de virtuales.

• Murano (catálogo de aplicaciones): Murano ofrece a los desarrolladores y a los administradores de la nube la opción de desplegar aplicaciones en un catálogo explorable clasificado por categorías.

• Manila (Shared File System): Este es un módulo opcional para OpenStack que amplía la arquitectura del sistema operativo con un sistema de archivos común y distribuido.

• Magnum (Container API Service): este servicio de API es un importante componente opcional que hace posible disponer de herramientas de orquestación de contenedores como Docker Swarm, Kubernetes o Apache Mesos como componentes de OpenStack.

Esta tipología modular y su posibilidad de ampliación son precisamente los factores que han convertido a OpenStack en uno de los sistemas operativos más relevantes a la hora de construir y operar estructuras en la nube basadas en código abierto. Gracias al controlador de Docker para Nova, OpenStack constituye una plataforma de gran rendimiento con la cual ejecutar y administrar contenedores de forma profesional en sistemas complejos y distribuidos.

DC/OS utiliza el kernel distribuido de Mesos. Esto permite agrupar los recursos de todo un centro de datos y gestionarlos como un único servidor lógico en la forma de sistema agregado. Es así como se pueden coordinar clústeres enteros de máquinas físicas o virtuales con la misma ligereza con la que se utiliza un solo ordenador.

El software simplifica la instalación y la gestión de aplicaciones distribuidas y automatiza la gestión de recursos, el reparto de tareas y la comunicación dentro de los procesos entre otras funciones. Tanto los clústeres basados en DC/OS como todos los servicios ejecutados en ellos se gestionan de forma centralizada a través de un programa de líneas de comando (CLI) o de una interfaz web (GUI).

DC/OS abstrae los recursos del clúster y suministra servicios comunes como Service Discovery o gestión de paquetes. Los componentes nucleares del software se ejecutan en un espacio protegido, el espacio kernel, al que pertenecen programas maestro y agente de la plataforma Mesos responsables de la clasificación de recursos, del aislamiento de procesos y de las funciones de seguridad.

• Mesos Master: este es un proceso maestro que se ejecuta en un nodo maestro en un clúster y se encarga de la gestión de recursos y de la coordinación de Tasks (unidades de trabajo abstractas) ejecutadas en un nodo agente. El maestro Mesos distribuye para ello los recursos entre servicios DC/OS y recibe los informes de los recursos de los agentes Mesos.

• Mesos Agents: los agentes Mesos son procesos esclavo que se ejecutan en nodos agente y que son responsables de la ejecución de las tasks repartidas por el maestro. Estos agentes entregan al maestro informes sobre los recursos disponibles en el clúster periódicamente, que el maestro envía a un planificador o scheduler (Marathon, Chronos o Cassandra). Este decide qué tarea se ejecutará en qué nodo. Para ejecutar una tarea, el agente inicia un proceso que se denomina “ejecutor” (executor) que corre y se gestiona de forma aislada en un contenedor. La división de los procesos tiene lugar bien a través del Mesos Universal Container Runtime o de la Docker Container Plattform.

El resto de componentes del sistema, así como las aplicaciones que ejecutan los agentes Mesos mediante el executor tienen lugar en el User Space. Entre los componentes básicos de una instalación DC/OS estándar se cuentan el Admin Router, el DNS de Mesos, un proxy DNS distribuido, el balanceador de carga Minuteman, el scheduler Marathon, Apache ZooKeeper y Exhibitor. Los detallamos a continuación:

• Admin Router: este es un servidor web basado en NGINX y configurado de forma especial que suministra tanto servicios DC/OS como funciones centrales de verificación y proxy.

• Mesos DNS: este componente incluye funciones de Service Discovery que permiten a todos los servicios y aplicaciones en el clúster identificarse mutuamente mediante un DNS central.

• Distributed DNS Proxy: se trata de un repartidor (dispatcher) DNS interno.

• Minuteman: este componente actúa de balanceador de carga interno que trabaja en la capa de transporte (capa 4) del modelo de referencia OSI.

• DC/OS Marathon: este es un componente central de la plataforma Mesos con funciones de init-System (parecido a systemd) en Mesosphere DC/OS. Marathon inicia y supervisa servicios DC/OS y aplicaciones en entornos clúster, ofreciendo, además, funciones de alta disponibilidad, Service Discovery, balanceo de carga, chequeos de salud y una interfaz web gráfica.

• Apache ZooKeeper: en el caso de Apache Zookeeper, se trata de un componente de software libre que ofrece funciones de coordinación para gestionar y operar aplicaciones en sistemas distribuidos. En Mesosphere DC/OS Apache ZooKeeper se aplica para coordinar todos los servicios del sistema instalados.

• Exhibitor: gracias a este componente, Zookeeper se puede instalar y configurar de forma automática en cada nodo maestro de un clúster. Exhibitor incluye además una interfaz gráfica de usuario para los usuarios de Zookeeper.

En aquellos recursos del clúster agregados con DC/OS se pueden ejecutar diversas tareas al mismo tiempo, de tal forma que el sistema operativo del clúster permite, por ejemplo, el funcionamiento en paralelo de sistemas Big Data, microservicios o plataformas de contenedores como Hadoop, Spark y Docker.

Mesosphere Universe dispone un catálogo público de aplicaciones para DC/OS con el cual se pueden instalar aplicaciones como Spark, Cassandra, Chronos, Jenkins o Kafka muy fácilmente a través de la interfaz de usuario.

A todo esto, una plataforma contenerizadora como Docker ofrece la oportunidad de optimizar las aplicaciones en cuanto a velocidad, rendimiento y gestión de cambios. Sin embargo, en cuanto a la seguridad de la tecnología de contenedores, aún quedan dudas por resolver.

Las aplicaciones basadas en contenedores se pueden instalar en cualquier sistema siempre y cuando se haya instalado antes el motor contenerizador. Los contenedores, además del código mismo de la aplicación, también contienen todos los archivos binarios y todas las bibliotecas que son necesarios para el tiempo de ejecución de la aplicación. Esto simplifica sobre todo el despliegue, esto es, la distribución del software en diferentes sistemas, y no solo para aplicaciones recién desarrolladas. La tecnología de contenedores también se puede aplicar de forma efectiva a la hora de traspasar legacy applications (aplicaciones obsoletas que aún siguen siendo imprescindibles en el día a día) a la nube.

Dado que los componentes de software más anticuados suelen ser difíciles de integrar en infraestructuras cloud por sus dependencias respecto a ciertos sistemas operativos, frameworks o clases, una plataforma ligera de contenedores como Docker puede ofrecer la capa de abstracción que sea capaz de compensar las dependencias de código sin que los administradores tengan que resignarse a aceptar la sobrecarga de un sistema operativo virtual.

Si se compara la tecnología de contenedores en la base de Docker con la virtualización clásica de hardware con máquinas virtuales, saltan a la vista las diferencias en cuanto a velocidad y rendimiento.

Dado que las aplicaciones, encerradas en contenedores, tienen acceso directo al núcleo del sistema host, este tipo de virtualización no requiere iniciar ningún sistema invitado separado. En lugar de un hipervisor, Docker utiliza un motor contenerizador muy liviano, de forma que no solo se ahorra en el tiempo que una máquina virtual necesita para arrancar, sino también en los recursos que un sistema operativo adicional necesita. Esto conlleva que las aplicaciones se puedan desplegar más rápido y sin gastar tantos recursos del sistema que aquellas aplicaciones en máquinas virtuales, de tal modo que la administración puede iniciar muchos más contenedores en un sistema host que sistemas invitados en una plataforma de hardware equiparable: si un servidor pudiera albergar entre 10 y 100 máquinas virtuales, esto equivaldría a mil contenedores. A esto se añade que los contenedores necesitan mucho menos espacio en memoria que una máquina virtual junto con la aplicación y el sistema operativo, dado que, aparte del código de la aplicación, los contenedores solo contienen archivos binarios y bibliotecas.

Aun cuando los procesos aislados en contenedores se ejecutan en el mismo kernel, Docker utiliza una serie de técnicas de aislamiento para protegerlos mutuamente. Las más importantes son las funciones centrales del kernel de Linux como Cgroups y Namespaces. Cada contenedor recibe un nombre de host propio, identificadores de proceso individuales y una interfaz de red particular y en su campo de visión se sitúa únicamente el fragmento del sistema de archivos que se le ha asignado. El reparto de los recursos del sistema (memoria, CPU, ancho de banda) tiene lugar por medio de un mecanismo Cgroup que garantiza que cada contenedor solo pueda consumir el contingente reservado para él.

Con ello, los contenedores no ofrecen el mismo grado de aislamiento que el que se puede alcanzar con máquinas virtuales. En el caso de que un atacante se hiciera con una máquina virtual, no tendría apenas posibilidades de entrar en contacto con el núcleo del sistema host subyacente. Los contenedores, en cambio, como instancias encapsuladas de un kernel host común, proporcionan un mayor margen de libertad a cualquier tipo de ataque.

A pesar de las técnicas de aislamiento que se han descrito, desde los contenedores es posible alcanzar importantes sistemas secundarios del kernel como Cgroups o las interfaces del kernel en los directorios /sys y /proc y estos ofrecen a los atacantes la posibilidad de esquivar las funciones de seguridad del host. Y dado que todos los contenedores se ejecutan en el mismo sistema host en el mismo espacio de nombres del usuario, un contenedor al que le hayan sido asignados derechos admin (root) también los mantiene en la interacción con el núcleo del host.  En consecuencia, los administradores solo deberían iniciar los contenedores con derechos limitados.

El demonio de Docker, responsable de la gestión del contenedor en el sistema anfitrión, también disfruta de derechos root, así que un usuario con acceso al demonio obtiene automáticamente acceso a todos los directorios a los que se le ha autorizado el acceso así como la posibilidad de comunicarse con una API REST utilizando HTTP. Es por esto que en su documentación Docker recomienda proveer de acceso al demonio solo a usuarios de confianza.

El equipo de desarrollo detrás de Docker también es consciente de estos problemas de seguridad, considerándolos un obstáculo para la consolidación de esta tecnología en sistemas productivos. Junto a las técnicas de aislamiento fundamentales del kernel de Linux, las últimas versiones del Engine Docker soportan, en consecuencia, los frameworks AppArmor, SELinux y Seccomp, que actuarían como una especie de cortafuegos para los recursos del kernel:

• AppArmor permite regular los derechos de acceso de los contenedores al sistema de archivos.

• SELinux presenta un complejo sistema de reglas con el cual se pueden implementar controles de acceso a los recursos del kernel.

• Seccomp (Secure Computing Mode) supervisa la llamada de systemcalls.

Sumándose a estos frameworks, Docker también utiliza las llamadas “capabilities” de Linux con las que se pueden limitar los derechos raíz con los cuales el Docker Engine arranca los contenedores.

Algunas debilidades de software contenidas en componentes de las aplicaciones que se expanden a través del registry de Docker también son fuente de objeciones. En principio no hay restricciones en cuanto a la creación y publicación de imágenes en el Docker Hub y esto es lo que conlleva el riesgo de introducir código maligno en un sistema por la descarga de una imagen. Por ello, antes del despliegue de una aplicación, los usuarios de Docker siempre deberían asegurarse de que el código completo suministrado por una imagen para ejecutar contenedores proceda de una fuente fiable. Docker ofrece desde comienzos de 2017 en la edición Enterprise (EE) un programa de certificación con la cual se pueden examinar y galardonar a proveedores de infraestructura, de contenedores y de extensiones. Para obtener un certificado han de cumplirse los siguientes requisitos:

• Certificado de infraestructura: aquellos desarrolladores de software con intención de suministrar componentes infraestructurales certificados para el ecosistema de Docker han de probar con ayuda de las herramientas correspondientes que su producto ha sido optimizado para trabajar conjuntamente con la plataforma Docker.

• Certificado de contenedores: un contenedor solo puede ser distinguido con un certificado oficial de Docker cuando se crea según las mejores prácticas y cuando ha superado todos los tests de software, los exámenes de debilidades y los chequeos de seguridad.

• Certificado de plugins: un plugin para Docker EE solo puede certificarse cuando se crea siguiendo las mejores prácticas y ha superado todos los exámenes de API Compliance y de debilidades.

Además de un aumento de la seguridad para los usuarios, los certificados de Docker aspiran a ofrecer a los desarrolladores de software la posibilidad de destacar con sus proyectos entre los numerosos recursos disponibles.

La tecnología de contenedores ya no es un tema de culto. Empresas de la envergadura de Spotify, ING Direct, eBay, PayPal o Netflix ya la han incluido en su infraestructura de TI. Esta tecnología representa una alternativa a la clásica virtualización de hardware que consume recursos de una forma más racional y adecuada sobre todo para aquellas empresas que despliegan aplicaciones web interactivas o han de gestionar un voluminoso conjunto de datos. Tanto es así que en los próximos años, especialmente en el ámbito del eCommerce, se espera que la demanda aumente. En el caso de global players como eBay o Amazon, los contenedores forman parte ya de su tecnología estándar. Los comerciantes menores no tardarán mucho.

En pocos años la joven compañía de software Docker ha logrado posicionarse como líder tecnológico del mercado de la virtualización en el nivel del sistema operativo gracias a su código abierto y a sus esfuerzos de estandarización. No obstante, la competencia no descansa. De esta rivalidad entre proveedores de soluciones de contenedores y herramientas de administración quien sale beneficiado es, sin duda, el usuario.

Sin embargo, en los últimos años los que más han frenado la expansión de la tecnología de contenedores han sido, sobre todo, los problemas de seguridad. El desafío principal para los desarrolladores de técnicas de virtualización con contenedores es la mejora del aislamiento de procesos en el kernel de Linux, un terreno en el cual se han alcanzado, ya en el pasado, grandes avances de la mano de proyectos como SELinux, AppArmor o Seccomp.

Echando un vistazo a la cuota de aceptación de los contenedores, es fácil predecir que este tipo de virtualización se consolide a largo plazo como alternativa a las máquinas virtuales. El proyecto Docker y su ecosistema en constante crecimiento ofrecen a las empresas una base duradera para operar en el futuro contenedores de software en el desarrollo y en el sector operativo.