Docker tools

El amplio ecosistema de Docker ofrece a los desarrolladores numerosas opciones para desplegar aplicaciones y orquestar contenedores, entre otros aspectos. A continuación, presentamos las Docker tools más significativas y los proyectos de terceros más populares que están desarrollando herramientas de código abierto para Docker.

Las Docker tools más básicas y sus componentes

Docker es hoy mucho más que una plataforma para la gestión de contenedores de software ligera. Para que el despliegue de aplicaciones en infraestructuras y entornos en la nube distribuidos sea más sencillo, rápido y flexible, el equipo de desarrollo ha puesto a disposición diversas Dockers Tools que ofrecen a los usuarios funciones de clúster y orquestación, un mercado central de aplicaciones y una herramienta para gestionar recursos en la nube.

Docker Engine

Cuando se habla de Docker, generalmente se hace referencia a la aplicación cliente-servidor de código abierto en la que se basa la plataforma de contenedores, que, en la nomenclatura propia, lleva el nombre de Docker Engine. Los componentes centrales del motor de Docker son el Docker Daemon, una API basada en REST y una CLI (Command Line Interface) como interfaz de usuario. Esta estructura es la que permite dirigir el motor de Docker mediante comandos y gestionar las imágenes, archivos de Docker y contenedores desde el terminal. El cliente y el daemon pueden estar ubicados en sistemas diferentes. Puedes encontrar una presentación general de los comandos de Docker más importantes en nuestro artículo adicional.

Docker Hub

Con Docker Hub, los usuarios disponen de un servidor de registros en la nube desde el cual se pueden descargar, gestionar y compartir imágenes de Docker. Una vez registrados, los usuarios pueden optar por guardar las imágenes en repositorios públicos o privados. Un sistema integrado de etiquetas permite el versionado de imágenes.

Además de repositorios públicos de otros usuarios, en el Docker Hub también se encuentran múltiples recursos ofrecidos por equipos de desarrollo y reconocidos proyectos open source en archivos de imágenes oficiales. Entre las imágenes de Docker más populares se cuentan el servidor web NGINX, la base de datos In Memory Redis, el kit de herramientas de Linux BusyBox y la distribución Linux Ubuntu.

Otra prestación del Docker Hub la conforman las denominadas organizations, grupos de trabajo que permiten a los usuarios de la plataforma mostrar repositorios privados a ciertos círculos. Los derechos de acceso se gestionan internamente mediante equipos y afiliaciones de grupo.

Docker Swarm

El Docker Engine contiene funciones nativas que permiten al usuario gestionar hosts de Docker en clústeres, que se denominan “swarms” (“enjambres”). Estas funciones de gestión de clústeres y de orquestación integradas en el motor de Docker se basan en la toolbox Swarmkit.

La herramienta nativa de clustering Swarm agrupa una serie de Docker hosts en un único host virtual y se sirve de la API de Docker para que cualquier Docker tool que tenga contacto con el Docker Daemon pueda acceder a Swarm y se pueda escalar en un número determinado de hosts. Los usuarios utilizan la CLI del motor de Docker para crear enjambres, distribuir aplicaciones en el clúster y dirigir el comportamiento del enjambre. No requiere un software de orquestación adicional.

Aquellos Docker Engines que han sido unidos en clústeres funcionan en modo swarm. Este modo se activa para crear un clúster nuevo o añadir a un swarm un host que ya existe. Cada uno de los hosts en un clúster pasa a ser un “nodo” y estos nodos pueden ejecutarse como hosts virtuales en el mismo sistema local, aunque la variante más habitual consiste en una estructura basada en la nube en la cual los nodos del enjambre se distribuyen en varios sistemas e infraestructuras.

En la base de este software se encuentra una arquitectura maestro esclavo: cuando se tienen que distribuir tareas en el enjambre, los usuarios transfieren un denominado “servicio” al nodo gestor, que actúa de maestro en el clúster. Este maestro es responsable de la planificación de los contenedores en el clúster y actúa de interfaz primaria a la hora de acceder a recursos de Swarm.

El nodo gestor envía cada unidad de trabajo por separado, las denominadas “tasks” (tareas), a esclavos subordinados, conocidos como “worker nodes” (nodos trabajadores) en la terminología Docker.

• Services: los servicios son estructuras centrales en los clústeres Docker. Un servicio es un grupo de contenedores basado en una misma imagen y define las tareas que se han de ejecutar en el clúster. Un usuario que crea un servicio especifica en él qué imágenes se han de utilizar y qué comandos se han de utilizar. También brindan la oportunidad de escalar aplicaciones. Para ello los usuarios de Docker solo han de definir cuántos contenedores se han de iniciar para un servicio.

• Tasks: para poder repartir servicios en el clúster, el nodo maestro los descompone en unidades independientes o tareas. Cada una de ellas incluye un contenedor y los comandos que se ejecutan en él.

Junto a funciones para dirigir el clúster y orquestar los contenedores, los nodos maestro también cumplen funciones de nodo trabajador en la configuración estándar, a no ser que el usuario limite sus funciones a las tareas de gestión.

En cada nodo trabajador funciona un programa agente (agent programm). Este programa recibe las tareas y entrega al nodo maestro correspondiente informes sobre el avance de la tarea que ha transferido. El gráfico siguiente representa a grandes trazos un enjambre Docker:

A la hora de implementar un Docker Swarm, los usuarios suelen recurrir a la Docker Machine.

Docker Compose

Docker Compose permite conectar varios contenedores y ejecutarlos con un único comando. Su componente fundamental es un archivo de control central basado en el lenguaje de marcado YAML. La sintaxis de este archivo se asemeja a la del software open source Vagrant, utilizado en la creación y aprovisionamiento de máquinas viruales.

En el archivo docker-compose.yml se pueden definir tantos contenedores de software como se desee incluyendo todas las dependencias, así como sus interrelaciones. El esquema seguido para dirigir las aplicaciones multicontenedor no difiere del necesario para gestionar contenedores simples. Con el comando docker-compose y el subcomando correspondiente se gestiona el ciclo vital completo de la aplicación.

Esta herramienta de orquestación se puede integrar fácilmente en un clúster basado en Swarm. Las aplicaciones multicontenedor creadas con Compose se ejecutan en sistemas distribuidos tan cómodamente como en hosts aislados.

Otra característica de Docker Compose es su mecanismo integrado de escalado: a través del programa de líneas de comando, con esta tool de Docker se puede definir cuántos contenedores se han de arrancar para un determinado servicio.

Docker tools de proveedores externos

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 D2iQ DC/OS, basado en el gestor de clústeres Mesos.

Kubernetes

Hubo un tiempo en el que Docker no podía suministrar herramientas propias de orquestación como Swarm und 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 encuentra el proyecto open source Kubernetes.

Kubernetes es un gestor de clústeres para aplicaciones contenerizadas. Su objetivo es automatizar la gestión de aplicaciones en clústeres. Para ello, esta herramienta de orquestación utiliza una API REST, un programa de líneas de comando y una interfaz web gráfica como interfaces de control, con las cuales lanzar automatismos y solicitar informes de estado. Los usuarios usan Kubernetes para:

• Ejecutar aplicaciones contenerizadas en un clúster
• Instalar y gestionar aplicaciones en sistemas distribuidos
• Escalar aplicaciones
• Aprovechar al máximo el hardware disponible

Para ello, Kubernetes agrupa a los contenedores en fragmentos lógicos, los llamados “pods”, que son los que representan las unidades básicas del gestor, las cuales se pueden distribuir en el clúster por el método del scheduling.

Como Swarm, también Kubernetes se fundamenta en la arquitectura maestro-esclavo: un clúster se compone de un maestro (Kubernetes Master) y de diversos esclavos o Kubernetes Nodes (también llamados Worker o Minions). El maestro actúa como nivel de control central (Control Plane) en el clúster y está compuesto por cuatro elementos básicos que permiten coordinar la comunicación en el interior del clúster y repartir las tareas: un servidor API, la memoria de configuración etcd, un scheduler y un Controller Manager.

• Servidor API: en un clúster Kubernetes todos los automatismos se lanzan en un servidor API por medio de una API REST. Este servidor actúa de punto central de administración en el clúster.
• etcd: este key value store de código abierto puede considerarse la memoria de un clúster Kubernetes. Desarrollado por CoreOs en especial para sistemas distribuidos, etcd almacena datos de configuración y los facilita a los nodos. Esto permite administrar el estado actual del clúster en todo momento.
• Scheduler: el papel del planificador consiste en repartir los pods en el clúster, para lo cual averigua cuántos recursos necesita un Pod y los ajusta con los recursos de que dispone cada nodo en el clúster.
• Controller Manager: este es un servicio del maestro de Kubernetes que regula el estado del clúster y ejecuta tareas rutinarias, dirigiendo de este modo la orquestación. La obligación principal del “gestor del controlador” es garantizar que el estado del clúster se corresponda con el estado que se había definido previamente como objetivo.

Estos cuatro componentes de un maestro se pueden encontrar en un mismo host o estar repartidos en varios hosts en un clúster de alta disponibilidad.

Mientras que el maestro es responsable de la orquestación, los pods distribuidos en el clúster se ejecutan en los nodos (hosts subordinados al host del master). Para ello, en cada nodo tiene que correr un Container Engine, Docker en la práctica, aunque Kubernetes no está ligado a ningún motor de contenedores en concreto.

Además del Container Engine, los nodos de Kubernetes también incluyen estos componentes:

• kubelet: con este nombre se designa a un agente que, ejecutándose en cada nodo, lo dirige y gestiona. Como punto de contacto principal en los nodos, kubelet mantiene el diálogo con el maestro y se ocupa de que la información se envíe al nivel de control y de que este la reciba.
• kube-proxy: además, en cada nodo de Kubernetes, también corre este servicio de proxy encargado de que las peticiones que llegan del exterior se envíen al contenedor correspondiente y de proveer servicios a los usuarios de aplicaciones contenerizadas. Además de ello, el kube-proxy ofrece un rudimentario balanceo de carga.

El siguiente gráfico muestra esquemáticamente la arquitectura maestro-esclavo en la que se fundamenta la plataforma de orquestación Kubernetes:

Las funcionalidades de Kubernetes se pueden ampliar con un gran número de herramientas y extensiones. Entre las más conocidas se encuentran las herramientas de monitorización y diagnóstico de errores Prometheus, Weave Scope y sysdig, así como el gestor de paquetes Helm. A estas se suman algunos plugins para Apache Maven y Gradle, así como una Java API para controlar Kubernetes de forma remota.

Shipyard

Shipyard es una solución de gestión desarrollada por la comunidad de usuarios de Docker basada en Swarm 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.

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 abierto.

Panamax

El equipo de desarrolladores de la Docker Tool de código abierto Panamax se ha 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. Los componentes fundamentales de la arquitectura Panamax se pueden subdividir en dos grupos: suele distinguirse entre el cliente local Panamax por un lado y un número aleatorio de Remote Deployment Targets.

El cliente local de Panamax (Panamax Local Client) es el componente principal de las Docker tools. Se ejecuta en el sistema local y permite crear aplicaciones contenerizadas complejas. Panamax Local Client está conformado por los siguientes componentes:

• CoreOS: la instalación del cliente local de Panamax supone contar con la distribución de Linux CoreOs, especialmente orientada al software de contenerización, como sistema host. Con Panamax los usuarios no solo disponen de características propias de Docker, sino también de diversas funciones de CoreOS, entre las que se cuentan Fleet y Journalctl.
  • Fleet: en lugar de interactuar directamente con Docker, el cliente de Panamax utiliza Fleet para coordinar los contenedores. Fleet es un gestor de clústeres que controla el daemon de Linux systemd en clústeres de ordenadores.
  • Journalctl: el cliente de Panamax utiliza esta función para solicitar notificaciones Log de systemd desde el Journal.
  • Local Client Installer: el instalador del cliente local contiene todos los componentes necesarios para instalar el cliente de Panamax en un sistema local.
• Panamax Local Agent: el llamado agente local es el componente principal del cliente local y mantiene el contacto con otros componentes y dependencias a través de la API de Panamax. Entre estos se cuentan el host de Docker local, la interfaz de usuario de Panamax, los servidores de registro externos, así como los agentes remotos en los Deployment Targets del clúster. Con el fin de intercambiar información sobre aplicaciones en funcionamiento, el agente local interactúa en el sistema local a través de la API de Panamax con las siguientes interfaces de programación:
  • Docker Remote API: a través de la API remota de Docker, Panamax busca imágenes en el sistema local y solicita información de estado sobre contenedores en marcha.
  • etcd API: con esta API se envían datos al daemon de Fleet (CoreOS Fleet Daemon).
  • systemd-journal-gatewayd.services: con esta directriz, Panamax solicita información sobre servicios en activo (Journal output).

Además de estas, la API de Panamax también permite la interacción con API externas:

• Docker Registry API: con ella Panamax extrae Image-tags de Panamax del registro de Docker (Docker Registry).
• GitHub API: con ella se pueden subir plantillas de Panamax a repositorios GitHub.
• KissMetrics API: la API de Kissmetrics recolecta datos sobre plantillas que ejecutan los usuarios.
• Panamax UI: la interfaz de usuario de Panamax permite a los usuarios dirigir la herramienta de Docker en el sistema local con una interfaz gráfica. Con la API de Panamax se pueden enviar directamente los datos que introduce el usuario al agente local. La interfaz de usuario de Panamax está basada en CTL Base UI Kit, una biblioteca básica con componentes de UI para proyectos de CenturyLink.

A los nodos sin tareas de administración en un clúster de Docker se les llama, en la terminología Docker, Remote Deployment Targets. Estos están compuestos de un host Docker configurado con ayuda de los siguientes componentes para el despliegue de plantillas Panamax:

• Deployment Target Installer: el instalador inicia un host de Docker, que incluye un agente remoto Panamax y un adaptador de orquestación (Orchestration Adapter).
• Panamax Remote Agent: una vez instalado el agente remoto de Panamax, las aplicaciones se pueden repartir en el clúster a través del cliente local de Panamax. Este agente remoto se ejecuta como contenedor Docker en cada objetivo de despliegue (Deployment Target) en el clúster.
• Panamax Orchestration Adapter: en el adaptador de orquestación, la lógica de programa de cada una de las herramientas de orquestación disponible para Panamax se despliega en una capa del adaptador independiente. Es así como los usuarios tienen la posibilidad de poder escoger siempre la tecnología de orquestación exactamente compatible con cada entorno final. Los adaptadores predefinidos incluyen Kubernetes y Fleet:
  • Panamax Kubernetes Adapter: en combinación con el agente remoto de Panamax, el adaptador de Kubernetes permite distribuir plantillas de Panamax en clústeres Kubernetes.
  • Panamax Fleet Adapter: en cooperación con el agente remoto de Panamax, el adaptador de Fleet permite repartir plantillas de Panamax en clústeres controlados por el gestor de clústeres Fleet.

El gráfico que sigue muestra la interacción de cada componente de Panamax en un clúster Docker:

Panamax ofrece a los usuarios diversas tecnologías estándar de orquestación de contenedores en una interfaz gráfica de usuario, así como la posibilidad de administrar aplicaciones multicontenedor de gran complejidad en arquitecturas clúster en cualquier sistema, como podría ser un ordenador portátil.

Con el repositorio público de plantillas Panamax pone a disposición de los usuarios en GitHub una biblioteca libre de plantillas con diversos recursos.

Drone

Drone es una plataforma de integración continua ligera y poco exigente. Con esta Docker Tool, puedes cargar de forma automática la última versión desde un repositorio Git como GitHub y ejecutarla en contenedores Docker aislados para realizar pruebas. El usuario cuenta con la posibilidad de ejecutar cualquier suite de prueba y programar el envío a su correo de los informes y las notificaciones de estado. Para cada prueba de software se genera un contenedor nuevo basado en una imagen del repositorio público de Docker, de tal forma que cualquier imagen de Docker disponible públicamente puede utilizarse como entorno para el código que se quiere probar.

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.

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.

OpenStack

Cuando se trata de construir y gestionar estructuras Cloud basadas en código abierto, el sistema operativo en la nube OpenStack es la solución de software perfecta. OpenStack permite administrar los recursos de computación, de memoria y de red de un centro de datos desde un panel de control central y ponerlos a disposición de los usuarios por medio de una interfaz web.

Este sistema operativo se basa en una arquitectura modular compuesta por distintos elementos:

• Zun (Servicio de contenedor): Zun es el servicio de contenedores de OpenStack que permite desplegar y gestionar fácilmente aplicaciones en contenedores en la nube OpenStack. El objetivo de Zun es permitir a los usuarios gestionar contenedores a través de una API REST sin necesidad de gestionar servidores o clústeres. Zun necesita otros tres servicios OpenStack para funcionar: Keystone, Neutron y kuryr-libnetwork. De forma opcional, se puede ampliar la funcionalidad de Zun con otros servicios de OpenStack, como Cinder y Glance.
• Neutron (componentes de red): Neutron (antaño Quantum) es un componente del sistema basado en API portable y escalable que se ocupa del control de la red. Este módulo provee una interfaz para topologías de red complejas y soporta extensiones diversas que permiten integrar funciones de red avanzadas.
• kuryr-libnetwork (controlador en Docker): kuryr-libnetwork es un controlador de Docker que actúa como interfaz entre Docker y Neutron.
• Keystone (servicio de identificación): con Keystone los usuarios de OpenStack disponen de un servicio central de identidad que hace las veces de sistema de autenticación y administración de derechos entre cada uno de los componentes de OpenStack. Cualquier acceso a proyectos en la nube es regulado con los denominados tenants (mandante), cada uno de los cuales representa una unidad-usuario. Por cada unidad-usuario se pueden definir varios accesos con derechos diferenciados.
• Cinder (sistema de almacenamiento en bloques): este es el nombre que se da a un componente de la arquitectura OpenStack que suministra memorias en bloque para el funcionamiento de máquinas virtuales. Este módulo provee memorias virtuales a través de una API Self Service. Con ella los usuarios pueden solicitar recursos de memoria sin que puedan ver en qué dispositivo se instala esta memoria.
• Glance: con este servicio, OpenStack permite almacenar y recuperar imágenes de máquinas virtuales.

Para más información sobre los componentes y servicios de OpenStack, accede a nuestro artículo sobre OpenStack. Además de los componentes listados, la arquitectura de OpenStack se puede ampliar con diversos módulos opcionales. Puedes encontrar más información en la página web de OpenStack.

D2iQ DC/OS

DC/OS (Distributed Cloud Operating System) es un software de código libre desarrollado por D2iQ (antes Mesosphere) para la gestión de sistemas distribuidos. El proyecto parte del gestor de clústeres open source Apache Mesos y está pensado como un sistema operativo para centros de datos. El código fuente de DC/OS está disponible en GitHub con una licencia Apache Version 2 y en d2iq.com sus desarrolladores comercializan una versión Enterprise del software. En dcos.io puede consultarse la detallada documentación del proyecto.

DC/OS puede ser considerado como una especie de distribución Mesos que a través de una interfaz central provee al usuario de todas las funciones del gestor de clústeres y lo amplía considerablemente.

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 D2iQ 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. Las tareas se aíslan y se ejecutan en un contenedor.

El resto de los 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 Domain NameSystem (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 D2iQ 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.

• 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.

El D2iQ 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.

Docker Tools para la seguridad

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. En particular, se utilizan las funciones centrales del kernel de Linux como Cgroups y Namespaces. Con ello, los contenedores no ofrecen el mismo grado de aislamiento que el que se puede alcanzar con máquinas virtuales.

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.

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.

Además de estas Docker Tools, 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 un programa de certificación con la cual se pueden examinar y galardonar a proveedores de infraestructura, de contenedores y de extensiones. Con este programa de certificación, Docker quiere facilitar a los desarrolladores la creación de cadenas de suministro de software seguras para sus proyectos.

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. Entre otros aspectos, las imágenes certificadas se clasifican mejor en los resultados de búsqueda de Docker Hub y se etiquetan con la insignia “Verified Publisher”.