Docker tools

El amplio eco­si­s­te­ma de Docker ofrece a los de­sa­rro­lla­do­res numerosas opciones para desplegar apli­ca­cio­nes y orquestar co­n­te­ne­do­res, entre otros aspectos. A co­n­ti­nua­ción, pre­se­n­ta­mos las Docker tools más si­g­ni­fi­ca­ti­vas y los proyectos de terceros más populares que están de­sa­rro­lla­n­do he­rra­mie­n­tas de código abierto para Docker.

Las Docker tools más básicas y sus co­m­po­ne­n­tes

Docker es hoy mucho más que una pla­ta­fo­r­ma para la gestión de co­n­te­ne­do­res de software ligera. Para que el de­s­plie­gue de apli­ca­cio­nes en in­frae­s­tru­c­tu­ras y entornos en la nube di­s­tri­bui­dos sea más sencillo, rápido y flexible, el equipo de de­sa­rro­llo ha puesto a di­s­po­si­ción diversas Dockers Tools que ofrecen a los usuarios funciones de clúster y or­que­s­ta­ción, un mercado central de apli­ca­cio­nes y una he­rra­mie­n­ta para gestionar recursos en la nube.

Docker Engine

Cuando se habla de Docker, ge­ne­ra­l­me­n­te se hace re­fe­re­n­cia a la apli­ca­ción cliente-servidor de código abierto en la que se basa la pla­ta­fo­r­ma de co­n­te­ne­do­res, que, en la no­me­n­cla­tu­ra propia, lleva el nombre de Docker Engine. Los co­m­po­ne­n­tes 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 es­tru­c­tu­ra es la que permite dirigir el motor de Docker mediante comandos y gestionar las imágenes, archivos de Docker y co­n­te­ne­do­res desde el terminal. El cliente y el daemon pueden estar ubicados en sistemas di­fe­re­n­tes. Puedes encontrar una pre­se­n­ta­ción general de los comandos de Docker más im­po­r­ta­n­tes 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 re­gi­s­tra­dos, los usuarios pueden optar por guardar las imágenes en re­po­si­to­rios públicos o privados. Un sistema integrado de etiquetas permite el ve­r­sio­na­do de imágenes.

Además de re­po­si­to­rios públicos de otros usuarios, en el Docker Hub también se en­cue­n­tran múltiples recursos ofrecidos por equipos de de­sa­rro­llo y re­co­no­ci­dos 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 he­rra­mie­n­tas de Linux BusyBox y la di­s­tri­bu­ción Linux Ubuntu.

Otra pre­s­ta­ción del Docker Hub la conforman las de­no­mi­na­das or­ga­ni­za­tio­ns, grupos de trabajo que permiten a los usuarios de la pla­ta­fo­r­ma mostrar re­po­si­to­rios privados a ciertos círculos. Los derechos de acceso se gestionan in­te­r­na­me­n­te mediante equipos y afi­lia­cio­nes 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 or­que­s­ta­ción in­te­gra­das en el motor de Docker se basan en la toolbox Swarmkit.

La he­rra­mie­n­ta nativa de clu­s­te­ri­ng 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 de­te­r­mi­na­do de hosts. Los usuarios utilizan la CLI del motor de Docker para crear enjambres, di­s­tri­buir apli­ca­cio­nes en el clúster y dirigir el co­m­po­r­ta­mie­n­to del enjambre. No requiere un software de or­que­s­ta­ció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 eje­cu­tar­se como hosts virtuales en el mismo sistema local, aunque la variante más habitual consiste en una es­tru­c­tu­ra basada en la nube en la cual los nodos del enjambre se di­s­tri­bu­yen en varios sistemas e in­frae­s­tru­c­tu­ras.

En la base de este software se encuentra una ar­qui­te­c­tu­ra maestro esclavo: cuando se tienen que di­s­tri­buir tareas en el enjambre, los usuarios tra­n­s­fie­ren un de­no­mi­na­do “servicio” al nodo gestor, que actúa de maestro en el clúster. Este maestro es re­s­po­n­sa­ble de la pla­ni­fi­ca­ción de los co­n­te­ne­do­res 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 de­no­mi­na­das “tasks” (tareas), a esclavos su­bo­r­di­na­dos, conocidos como “worker nodes” (nodos tra­ba­ja­do­res) en la te­r­mi­no­lo­gía Docker.

• Services: los servicios son es­tru­c­tu­ras centrales en los clústeres Docker. Un servicio es un grupo de co­n­te­ne­do­res basado en una misma imagen y define las tareas que se han de ejecutar en el clúster. Un usuario que crea un servicio es­pe­ci­fi­ca en él qué imágenes se han de utilizar y qué comandos se han de utilizar. También brindan la opo­r­tu­ni­dad de escalar apli­ca­cio­nes. Para ello los usuarios de Docker solo han de definir cuántos co­n­te­ne­do­res se han de iniciar para un servicio.

• Tasks: para poder repartir servicios en el clúster, el nodo maestro los de­s­co­m­po­ne en unidades in­de­pe­n­die­n­tes o tareas. Cada una de ellas incluye un co­n­te­ne­dor y los comandos que se ejecutan en él.

Junto a funciones para dirigir el clúster y orquestar los co­n­te­ne­do­res, los nodos maestro también cumplen funciones de nodo tra­ba­ja­dor en la co­n­fi­gu­ra­ción estándar, a no ser que el usuario limite sus funciones a las tareas de gestión.

En cada nodo tra­ba­ja­dor funciona un programa agente (agent programm). Este programa recibe las tareas y entrega al nodo maestro co­rre­s­po­n­die­n­te informes sobre el avance de la tarea que ha tra­n­s­fe­ri­do. El gráfico siguiente re­pre­se­n­ta a grandes trazos un enjambre Docker:

A la hora de im­ple­me­n­tar un Docker Swarm, los usuarios suelen recurrir a la Docker Machine.

Docker Compose

Docker Compose permite conectar varios co­n­te­ne­do­res y eje­cu­tar­los con un único comando. Su co­m­po­ne­n­te fu­n­da­me­n­tal 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 apro­vi­sio­na­mie­n­to de máquinas viruales.

En el archivo docker-compose.yml se pueden definir tantos co­n­te­ne­do­res de software como se desee in­clu­ye­n­do todas las de­pe­n­de­n­cias, así como sus in­ter­re­la­cio­nes. El esquema seguido para dirigir las apli­ca­cio­nes mu­l­ti­co­n­te­ne­dor no difiere del necesario para gestionar co­n­te­ne­do­res simples. Con el comando docker-compose y el su­b­co­ma­n­do co­rre­s­po­n­die­n­te se gestiona el ciclo vital completo de la apli­ca­ción.

Esta he­rra­mie­n­ta de or­que­s­ta­ción se puede integrar fá­ci­l­me­n­te en un clúster basado en Swarm. Las apli­ca­cio­nes mu­l­ti­co­n­te­ne­dor creadas con Compose se ejecutan en sistemas di­s­tri­bui­dos tan có­mo­da­me­n­te como en hosts aislados.

Otra ca­ra­c­te­rí­s­ti­ca 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 co­n­te­ne­do­res se han de arrancar para un de­te­r­mi­na­do servicio.

Docker tools de pro­vee­do­res externos

Sumándose a estos programas de­sa­rro­lla­dos por Docker Inc., algunos pro­vee­do­res externos también se han animado a de­sa­rro­llar he­rra­mie­n­tas y pla­ta­fo­r­mas que, o bien se pueden conectar con el Docker Engine o bien se han de­sa­rro­lla­do ex­clu­si­va­me­n­te para la popular pla­ta­fo­r­ma. Entre la di­ve­r­si­dad de proyectos de código abierto en­glo­ba­dos dentro del eco­si­s­te­ma de Docker se cuentan la he­rra­mie­n­ta de or­que­s­ta­ción Ku­be­r­ne­tes, el sistema de gestión de clústeres Shipyard, la solución de de­s­plie­gue de apli­ca­cio­nes mu­l­ti­co­n­te­ne­dor Panamax, la pla­ta­fo­r­ma de in­te­gra­ció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.

Ku­be­r­ne­tes

Hubo un tiempo en el que Docker no podía su­mi­ni­s­trar he­rra­mie­n­tas propias de or­que­s­ta­ción como Swarm und Compose. Es por eso que, desde hace años, numerosas empresas invierten en el de­sa­rro­llo de he­rra­mie­n­tas a medida para facilitar el fu­n­cio­na­mie­n­to de la pla­ta­fo­r­ma de co­n­te­ne­do­res en in­frae­s­tru­c­tu­ras grandes y di­s­tri­bui­das. Entre las so­lu­cio­nes más conocidas de este tipo se encuentra el proyecto open source Ku­be­r­ne­tes.

Ku­be­r­ne­tes es un gestor de clústeres para apli­ca­cio­nes co­n­te­ne­ri­za­das. Su objetivo es au­to­ma­ti­zar la gestión de apli­ca­cio­nes en clústeres. Para ello, esta he­rra­mie­n­ta de or­que­s­ta­ción utiliza una API REST, un programa de líneas de comando y una interfaz web gráfica como in­te­r­fa­ces de control, con las cuales lanzar au­to­ma­ti­s­mos y solicitar informes de estado. Los usuarios usan Ku­be­r­ne­tes para:

• Ejecutar apli­ca­cio­nes co­n­te­ne­ri­za­das en un clúster
• Instalar y gestionar apli­ca­cio­nes en sistemas di­s­tri­bui­dos
• Escalar apli­ca­cio­nes
• Apro­ve­char al máximo el hardware di­s­po­ni­ble

Para ello, Ku­be­r­ne­tes agrupa a los co­n­te­ne­do­res en fra­g­me­n­tos lógicos, los llamados “pods”, que son los que re­pre­se­n­tan las unidades básicas del gestor, las cuales se pueden di­s­tri­buir en el clúster por el método del sche­du­li­ng.

Como Swarm, también Ku­be­r­ne­tes se fu­n­da­me­n­ta en la ar­qui­te­c­tu­ra maestro-esclavo: un clúster se compone de un maestro (Ku­be­r­ne­tes Master) y de diversos esclavos o Ku­be­r­ne­tes 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 co­mu­ni­ca­ción en el interior del clúster y repartir las tareas: un servidor API, la memoria de co­n­fi­gu­ra­ción etcd, un scheduler y un Co­n­tro­ller Manager.

• Servidor API: en un clúster Ku­be­r­ne­tes todos los au­to­ma­ti­s­mos se lanzan en un servidor API por medio de una API REST. Este servidor actúa de punto central de ad­mi­ni­s­tra­ción en el clúster.
• etcd: este key value store de código abierto puede co­n­si­de­rar­se la memoria de un clúster Ku­be­r­ne­tes. De­sa­rro­lla­do por CoreOs en especial para sistemas di­s­tri­bui­dos, etcd almacena datos de co­n­fi­gu­ra­ción y los facilita a los nodos. Esto permite ad­mi­ni­s­trar el estado actual del clúster en todo momento.
• Scheduler: el papel del pla­ni­fi­ca­dor 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.
• Co­n­tro­ller Manager: este es un servicio del maestro de Ku­be­r­ne­tes que regula el estado del clúster y ejecuta tareas ru­ti­na­rias, di­ri­gie­n­do de este modo la or­que­s­ta­ción. La obli­ga­ción principal del “gestor del co­n­tro­la­dor” es ga­ra­n­ti­zar que el estado del clúster se co­rre­s­po­n­da con el estado que se había definido pre­via­me­n­te como objetivo.

Estos cuatro co­m­po­ne­n­tes de un maestro se pueden encontrar en un mismo host o estar re­pa­r­ti­dos en varios hosts en un clúster de alta di­s­po­ni­bi­li­dad.

Mientras que el maestro es re­s­po­n­sa­ble de la or­que­s­ta­ción, los pods di­s­tri­bui­dos en el clúster se ejecutan en los nodos (hosts su­bo­r­di­na­dos al host del master). Para ello, en cada nodo tiene que correr un Container Engine, Docker en la práctica, aunque Ku­be­r­ne­tes no está ligado a ningún motor de co­n­te­ne­do­res en concreto.

Además del Container Engine, los nodos de Ku­be­r­ne­tes también incluyen estos co­m­po­ne­n­tes:

• kubelet: con este nombre se designa a un agente que, eje­cu­tá­n­do­se 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 in­fo­r­ma­ción se envíe al nivel de control y de que este la reciba.
• kube-proxy: además, en cada nodo de Ku­be­r­ne­tes, también corre este servicio de proxy encargado de que las pe­ti­cio­nes que llegan del exterior se envíen al co­n­te­ne­dor co­rre­s­po­n­die­n­te y de proveer servicios a los usuarios de apli­ca­cio­nes co­n­te­ne­ri­za­das. Además de ello, el kube-proxy ofrece un ru­di­me­n­ta­rio balanceo de carga.

El siguiente gráfico muestra es­que­má­ti­ca­me­n­te la ar­qui­te­c­tu­ra maestro-esclavo en la que se fu­n­da­me­n­ta la pla­ta­fo­r­ma de or­que­s­ta­ción Ku­be­r­ne­tes:

Las fu­n­cio­na­li­da­des de Ku­be­r­ne­tes se pueden ampliar con un gran número de he­rra­mie­n­tas y ex­te­n­sio­nes. Entre las más conocidas se en­cue­n­tran las he­rra­mie­n­tas de mo­ni­to­ri­za­ción y dia­g­nó­s­ti­co de errores Pro­me­theus, 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 Ku­be­r­ne­tes de forma remota.

Shipyard

Shipyard es una solución de gestión de­sa­rro­lla­da por la comunidad de usuarios de Docker basada en Swarm que permite a los usuarios gestionar recursos de la pla­ta­fo­r­ma como co­n­te­ne­do­res, imágenes, hosts y re­po­si­to­rios privados a través de una interfaz gráfica de usuario. Shipyard está di­s­po­ni­ble como apli­ca­ción web.

El programa es co­m­ple­ta­me­n­te co­m­pa­ti­ble 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 di­re­c­cio­nes y los eventos. Además de proveer funciones de gestión de clústeres en una interfaz web central, la he­rra­mie­n­ta también incluye una función de ve­ri­fi­ca­ció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: Co­n­tro­ller, API y UI.

• Shipyard Co­n­tro­ller: este co­m­po­ne­n­te co­n­s­ti­tu­ye el corazón de Shypyard. El co­n­tro­la­dor in­ter­ac­túa con la base de datos RethinkDB para almacenar la in­fo­r­ma­ción y permite la co­mu­ni­ca­ció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 he­rra­mie­n­ta de gestión se controlan con ella.
• Shipyard User Interface (UI): la interfaz de usuario de Shipyard es una apli­ca­ción AngularJS que provee a los usuarios de una interfaz gráfica para gestionar los clústeres de Docker en el navegador. Todas las in­ter­ac­cio­nes 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 de­sa­rro­lla­do­res de la Docker Tool de código abierto Panamax se ha propuesto si­m­pli­fi­car el de­s­plie­gue de apli­ca­cio­nes mu­l­ti­co­n­te­ne­dor. La he­rra­mie­n­ta ofrece a los usuarios una interfaz gráfica con la cual se pueden de­sa­rro­llar, desplegar y di­s­tri­buir apli­ca­cio­nes complejas basadas en co­n­te­ne­do­res Docker se­n­ci­lla­me­n­te por drag and drop.

Panamax permite guardar estas apli­ca­cio­nes en la forma de pla­n­ti­llas de apli­ca­ción y re­pa­r­ti­r­las en es­tru­c­tu­ras clúster muy fá­ci­l­me­n­te. A través de un App Ma­r­ke­t­pla­ce integrado en la he­rra­mie­n­ta y alojado en GitHub, estas pla­n­ti­llas se pueden guardar y publicar en re­po­si­to­rios Git. Los co­m­po­ne­n­tes fu­n­da­me­n­ta­les de la ar­qui­te­c­tu­ra Panamax se pueden su­b­di­vi­dir en dos grupos: suele di­s­ti­n­gui­r­se entre el cliente local Panamax por un lado y un número aleatorio de Remote De­plo­y­me­nt Targets.

El cliente local de Panamax (Panamax Local Client) es el co­m­po­ne­n­te principal de las Docker tools. Se ejecuta en el sistema local y permite crear apli­ca­cio­nes co­n­te­ne­ri­za­das complejas. Panamax Local Client está co­n­fo­r­ma­do por los si­guie­n­tes co­m­po­ne­n­tes:

• CoreOS: la in­s­ta­la­ción del cliente local de Panamax supone contar con la di­s­tri­bu­ción de Linux CoreOs, es­pe­cia­l­me­n­te orientada al software de co­n­te­ne­ri­za­ción, como sistema host. Con Panamax los usuarios no solo disponen de ca­ra­c­te­rí­s­ti­cas propias de Docker, sino también de diversas funciones de CoreOS, entre las que se cuentan Fleet y Jou­r­na­l­ctl.
  • Fleet: en lugar de in­ter­ac­tuar di­re­c­ta­me­n­te con Docker, el cliente de Panamax utiliza Fleet para coordinar los co­n­te­ne­do­res. Fleet es un gestor de clústeres que controla el daemon de Linux systemd en clústeres de or­de­na­do­res.
  • Jou­r­na­l­ctl: el cliente de Panamax utiliza esta función para solicitar no­ti­fi­ca­cio­nes Log de systemd desde el Journal.
  • Local Client Installer: el in­s­ta­la­dor del cliente local contiene todos los co­m­po­ne­n­tes ne­ce­sa­rios para instalar el cliente de Panamax en un sistema local.
• Panamax Local Agent: el llamado agente local es el co­m­po­ne­n­te principal del cliente local y mantiene el contacto con otros co­m­po­ne­n­tes y de­pe­n­de­n­cias a través de la API de Panamax. Entre estos se cuentan el host de Docker local, la interfaz de usuario de Panamax, los se­r­vi­do­res de registro externos, así como los agentes remotos en los De­plo­y­me­nt Targets del clúster. Con el fin de in­te­r­ca­m­biar in­fo­r­ma­ción sobre apli­ca­cio­nes en fu­n­cio­na­mie­n­to, el agente local in­ter­ac­túa en el sistema local a través de la API de Panamax con las si­guie­n­tes in­te­r­fa­ces de pro­gra­ma­ción:
  • Docker Remote API: a través de la API remota de Docker, Panamax busca imágenes en el sistema local y solicita in­fo­r­ma­ción de estado sobre co­n­te­ne­do­res 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 in­fo­r­ma­ción sobre servicios en activo (Journal output).

Además de estas, la API de Panamax también permite la in­ter­ac­ció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 pla­n­ti­llas de Panamax a re­po­si­to­rios GitHub.
• Ki­s­s­Me­tri­cs API: la API de Ki­s­s­me­tri­cs recolecta datos sobre pla­n­ti­llas que ejecutan los usuarios.
• Panamax UI: la interfaz de usuario de Panamax permite a los usuarios dirigir la he­rra­mie­n­ta de Docker en el sistema local con una interfaz gráfica. Con la API de Panamax se pueden enviar di­re­c­ta­me­n­te los datos que introduce el usuario al agente local. La interfaz de usuario de Panamax está basada en CTL Base UI Kit, una bi­blio­te­ca básica con co­m­po­ne­n­tes de UI para proyectos de Ce­n­tu­r­y­Li­nk.

A los nodos sin tareas de ad­mi­ni­s­tra­ción en un clúster de Docker se les llama, en la te­r­mi­no­lo­gía Docker, Remote De­plo­y­me­nt Targets. Estos están co­m­pue­s­tos de un host Docker co­n­fi­gu­ra­do con ayuda de los si­guie­n­tes co­m­po­ne­n­tes para el de­s­plie­gue de pla­n­ti­llas Panamax:

• De­plo­y­me­nt Target Installer: el in­s­ta­la­dor inicia un host de Docker, que incluye un agente remoto Panamax y un adaptador de or­que­s­ta­ción (Or­che­s­tra­tion Adapter).
• Panamax Remote Agent: una vez instalado el agente remoto de Panamax, las apli­ca­cio­nes se pueden repartir en el clúster a través del cliente local de Panamax. Este agente remoto se ejecuta como co­n­te­ne­dor Docker en cada objetivo de de­s­plie­gue (De­plo­y­me­nt Target) en el clúster.
• Panamax Or­che­s­tra­tion Adapter: en el adaptador de or­que­s­ta­ción, la lógica de programa de cada una de las he­rra­mie­n­tas de or­que­s­ta­ción di­s­po­ni­ble para Panamax se despliega en una capa del adaptador in­de­pe­n­die­n­te. Es así como los usuarios tienen la po­si­bi­li­dad de poder escoger siempre la te­c­no­lo­gía de or­que­s­ta­ción exac­ta­me­n­te co­m­pa­ti­ble con cada entorno final. Los ada­p­ta­do­res pre­de­fi­ni­dos incluyen Ku­be­r­ne­tes y Fleet:
  • Panamax Ku­be­r­ne­tes Adapter: en co­m­bi­na­ción con el agente remoto de Panamax, el adaptador de Ku­be­r­ne­tes permite di­s­tri­buir pla­n­ti­llas de Panamax en clústeres Ku­be­r­ne­tes.
  • Panamax Fleet Adapter: en coope­ra­ción con el agente remoto de Panamax, el adaptador de Fleet permite repartir pla­n­ti­llas de Panamax en clústeres co­n­tro­la­dos por el gestor de clústeres Fleet.

El gráfico que sigue muestra la in­ter­ac­ción de cada co­m­po­ne­n­te de Panamax en un clúster Docker:

Panamax ofrece a los usuarios diversas te­c­no­lo­gías estándar de or­que­s­ta­ción de co­n­te­ne­do­res en una interfaz gráfica de usuario, así como la po­si­bi­li­dad de ad­mi­ni­s­trar apli­ca­cio­nes mu­l­ti­co­n­te­ne­dor de gran co­m­ple­ji­dad en ar­qui­te­c­tu­ras clúster en cualquier sistema, como podría ser un ordenador portátil.

Con el re­po­si­to­rio público de pla­n­ti­llas Panamax pone a di­s­po­si­ción de los usuarios en GitHub una bi­blio­te­ca libre de pla­n­ti­llas con diversos recursos.

Drone

Drone es una pla­ta­fo­r­ma de in­te­gra­ción continua ligera y poco exigente. Con esta Docker Tool, puedes cargar de forma au­to­má­ti­ca la última versión desde un re­po­si­to­rio Git como GitHub y eje­cu­tar­la en co­n­te­ne­do­res Docker aislados para realizar pruebas. El usuario cuenta con la po­si­bi­li­dad de ejecutar cualquier suite de prueba y programar el envío a su correo de los informes y las no­ti­fi­ca­cio­nes de estado. Para cada prueba de software se genera un co­n­te­ne­dor nuevo basado en una imagen del re­po­si­to­rio público de Docker, de tal forma que cualquier imagen de Docker di­s­po­ni­ble pú­bli­ca­me­n­te puede uti­li­zar­se como entorno para el código que se quiere probar.

Drone está integrado en Docker y soporta diversos lenguajes de pro­gra­ma­ción como PHP, Node.js, Ruby, Go o Python. La única de­pe­n­de­n­cia necesaria es pre­ci­sa­me­n­te la pla­ta­fo­r­ma de co­n­te­ne­do­res. Esto quiere decir que, para crear una pla­ta­fo­r­ma de in­te­gra­ción continua con Drone, es necesario hacerlo en un sistema en el cual esté instalado Docker. Drone soporta diversos re­po­si­to­rios de control de versiones. En la do­cu­me­n­ta­ción del proyecto se encuentra un manual con el nombre de readme.drone.io para la in­s­ta­la­ción estándar con in­te­gra­ción de GitHub.

Para ad­mi­ni­s­trar la pla­ta­fo­r­ma de CI se utiliza una interfaz web a través de la cual se cargan los builds de software desde cualquier re­po­si­to­rio Git, se agrupan apli­ca­cio­nes y se ejecuta el resultado en un entorno de pruebas pre­via­me­n­te 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 apli­ca­ción.

Con Drone, los usuarios disponen de una solución de CI de código abierto que aúna las ventajas de productos al­te­r­na­ti­vos como Travis y Jenkins en una apli­ca­ción sencilla y amigable.

OpenStack

Cuando se trata de construir y gestionar es­tru­c­tu­ras Cloud basadas en código abierto, el sistema operativo en la nube OpenStack es la solución de software perfecta. OpenStack permite ad­mi­ni­s­trar los recursos de co­mpu­tación, de memoria y de red de un centro de datos desde un panel de control central y ponerlos a di­s­po­si­ción de los usuarios por medio de una interfaz web.

Este sistema operativo se basa en una ar­qui­te­c­tu­ra modular compuesta por distintos elementos:

• Zun (Servicio de co­n­te­ne­dor): Zun es el servicio de co­n­te­ne­do­res de OpenStack que permite desplegar y gestionar fá­ci­l­me­n­te apli­ca­cio­nes en co­n­te­ne­do­res en la nube OpenStack. El objetivo de Zun es permitir a los usuarios gestionar co­n­te­ne­do­res a través de una API REST sin necesidad de gestionar se­r­vi­do­res o clústeres. Zun necesita otros tres servicios OpenStack para funcionar: Keystone, Neutron y kuryr-li­b­ne­t­wo­rk. De forma opcional, se puede ampliar la fu­n­cio­na­li­dad de Zun con otros servicios de OpenStack, como Cinder y Glance.
• Neutron (co­m­po­ne­n­tes de red): Neutron (antaño Quantum) es un co­m­po­ne­n­te del sistema basado en API portable y escalable que se ocupa del control de la red. Este módulo provee una interfaz para to­po­lo­gías de red complejas y soporta ex­te­n­sio­nes diversas que permiten integrar funciones de red avanzadas.
• kuryr-li­b­ne­t­wo­rk (co­n­tro­la­dor en Docker): kuryr-li­b­ne­t­wo­rk es un co­n­tro­la­dor de Docker que actúa como interfaz entre Docker y Neutron.
• Keystone (servicio de ide­n­ti­fi­ca­ción): con Keystone los usuarios de OpenStack disponen de un servicio central de identidad que hace las veces de sistema de au­te­n­ti­ca­ción y ad­mi­ni­s­tra­ción de derechos entre cada uno de los co­m­po­ne­n­tes de OpenStack. Cualquier acceso a proyectos en la nube es regulado con los de­no­mi­na­dos tenants (mandante), cada uno de los cuales re­pre­se­n­ta una unidad-usuario. Por cada unidad-usuario se pueden definir varios accesos con derechos di­fe­re­n­cia­dos.
• Cinder (sistema de al­ma­ce­na­mie­n­to en bloques): este es el nombre que se da a un co­m­po­ne­n­te de la ar­qui­te­c­tu­ra OpenStack que su­mi­ni­s­tra memorias en bloque para el fu­n­cio­na­mie­n­to 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é di­s­po­si­ti­vo se instala esta memoria.
• Glance: con este servicio, OpenStack permite almacenar y recuperar imágenes de máquinas virtuales.

Para más in­fo­r­ma­ción sobre los co­m­po­ne­n­tes y servicios de OpenStack, accede a nuestro artículo sobre OpenStack. Además de los co­m­po­ne­n­tes listados, la ar­qui­te­c­tu­ra de OpenStack se puede ampliar con diversos módulos op­cio­na­les. Puedes encontrar más in­fo­r­ma­ción en la página web de OpenStack.

D2iQ DC/OS

DC/OS (Di­s­tri­bu­ted Cloud Operating System) es un software de código libre de­sa­rro­lla­do por D2iQ (antes Me­so­s­phe­re) para la gestión de sistemas di­s­tri­bui­dos. 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á di­s­po­ni­ble en GitHub con una licencia Apache Version 2 y en d2iq.com sus de­sa­rro­lla­do­res co­me­r­cia­li­zan una versión En­te­r­pri­se del software. En dcos.io puede co­n­su­l­tar­se la detallada do­cu­me­n­ta­ción del proyecto.

DC/OS puede ser co­n­si­de­ra­do como una especie de di­s­tri­bu­ció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 co­n­si­de­ra­ble­me­n­te.

DC/OS utiliza el kernel di­s­tri­bui­do de Mesos. Esto permite agrupar los recursos de todo un centro de datos y ge­s­tio­nar­los 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 si­m­pli­fi­ca la in­s­ta­la­ción y la gestión de apli­ca­cio­nes di­s­tri­bui­das y au­to­ma­ti­za la gestión de recursos, el reparto de tareas y la co­mu­ni­ca­ción dentro de los procesos entre otras funciones. Tanto los clústeres basados en D2iQ DC/OS como todos los servicios eje­cu­ta­dos en ellos se gestionan de forma ce­n­tra­li­za­da 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 su­mi­ni­s­tra servicios comunes como Service Discovery o gestión de paquetes. Los co­m­po­ne­n­tes nucleares del software se ejecutan en un espacio protegido, el espacio Kernel, al que pe­r­te­ne­cen programas maestro y agente de la pla­ta­fo­r­ma Mesos re­s­po­n­sa­bles de la cla­si­fi­ca­ción de recursos, del ai­s­la­mie­n­to 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 coor­di­na­ción de Tasks (unidades de trabajo ab­s­tra­c­tas) eje­cu­ta­das en un nodo agente. El maestro Mesos di­s­tri­bu­ye 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 re­s­po­n­sa­bles de la ejecución de las tasks re­pa­r­ti­das por el maestro. Estos agentes entregan al maestro informes sobre los recursos di­s­po­ni­bles en el clúster pe­rió­di­ca­me­n­te, que el maestro envía a un pla­ni­fi­ca­dor 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 co­n­te­ne­dor.

El resto de los co­m­po­ne­n­tes del sistema, así como las apli­ca­cio­nes que ejecutan los agentes Mesos mediante el executor, tienen lugar en el User Space. Entre los co­m­po­ne­n­tes básicos de una in­s­ta­la­ción DC/OS estándar se cuentan el Admin Router, el DNS de Mesos, un proxy DNS di­s­tri­bui­do, el ba­la­n­cea­dor de carga Minuteman, el scheduler Marathon, Apache ZooKeeper y Exhibitor. Los de­ta­lla­mos a co­n­ti­nua­ción:

• Admin Router: este es un servidor web basado en NGINX y co­n­fi­gu­ra­do de forma especial que su­mi­ni­s­tra tanto servicios DC/OS como funciones centrales de ve­ri­fi­ca­ción y proxy.

• Mesos DNS: este co­m­po­ne­n­te incluye funciones de Service Discovery que permiten a todos los servicios y apli­ca­cio­nes en el clúster ide­n­ti­fi­car­se mu­tua­me­n­te mediante un Domain Na­me­S­y­s­tem (DNS) central.

• Di­s­tri­bu­ted DNS Proxy: se trata de un re­pa­r­ti­dor (di­s­pa­t­cher) DNS interno.

• Minuteman: este co­m­po­ne­n­te actúa de ba­la­n­cea­dor de carga interno que trabaja en la capa de tra­n­s­po­r­te (capa 4) del modelo de re­fe­re­n­cia OSI.

• DC/OS Marathon: este es un co­m­po­ne­n­te central de la pla­ta­fo­r­ma Mesos con funciones de init-System (parecido a systemd) en D2iQ DC/OS. Marathon inicia y supervisa servicios DC/OS y apli­ca­cio­nes en entornos clúster, ofre­cie­n­do, además, funciones de alta di­s­po­ni­bi­li­dad, Service Discovery, balanceo de carga, chequeos de salud y una interfaz web gráfica.

• Exhibitor: gracias a este co­m­po­ne­n­te, Zookeeper se puede instalar y co­n­fi­gu­rar de forma au­to­má­ti­ca 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 fu­n­cio­na­mie­n­to en paralelo de sistemas Big-Data, mi­cro­se­r­vi­cios o pla­ta­fo­r­mas de co­n­te­ne­do­res como Hadoop, Spark y Docker.

El D2iQ Universe dispone un catálogo público de apli­ca­cio­nes para DC/OS con el cual se pueden instalar apli­ca­cio­nes como Spark, Cassandra, Chronos, Jenkins o Kafka muy fá­ci­l­me­n­te a través de la interfaz de usuario.

Docker Tools para la seguridad

Aun cuando los procesos aislados en co­n­te­ne­do­res se ejecutan en el mismo kernel, Docker utiliza una serie de técnicas de ai­s­la­mie­n­to para pro­te­ge­r­los mu­tua­me­n­te. En pa­r­ti­cu­lar, se utilizan las funciones centrales del kernel de Linux como Cgroups y Na­me­s­pa­ces. Con ello, los co­n­te­ne­do­res no ofrecen el mismo grado de ai­s­la­mie­n­to que el que se puede alcanzar con máquinas virtuales.

A pesar de las técnicas de ai­s­la­mie­n­to que se han descrito, desde los co­n­te­ne­do­res es posible alcanzar im­po­r­ta­n­tes sistemas se­cu­n­da­rios del kernel como Cgroups o las in­te­r­fa­ces del kernel en los di­re­c­to­rios /sys y /proc.

El equipo de de­sa­rro­llo detrás de Docker también es co­n­s­cie­n­te de estos problemas de seguridad, co­n­si­de­rá­n­do­los un obstáculo para la co­n­so­li­da­ción de esta te­c­no­lo­gía en sistemas pro­du­c­ti­vos. Junto a las técnicas de ai­s­la­mie­n­to fu­n­da­me­n­ta­les del kernel de Linux, las últimas versiones del Engine Docker soportan, en co­n­se­cue­n­cia, los fra­me­wo­r­ks AppArmor, SELinux y Seccomp, que actuarían como una especie de co­r­ta­fue­gos para los recursos del kernel:

• AppArmor: permite regular los derechos de acceso de los co­n­te­ne­do­res al sistema de archivos.
• SELinux: presenta un complejo sistema de reglas con el cual se pueden im­ple­me­n­tar controles de acceso a los recursos del kernel.
• Seccomp: (Secure Computing Mode) supervisa la llamada de sy­s­te­m­ca­lls.

Además de estas Docker Tools, Docker también utiliza las llamadas “ca­pa­bi­li­ties” de Linux con las que se pueden limitar los derechos raíz con los cuales el Docker Engine arranca los co­n­te­ne­do­res.

Algunas de­bi­li­da­des de software co­n­te­ni­das en co­m­po­ne­n­tes de las apli­ca­cio­nes que se expanden a través del registry de Docker también son fuente de ob­je­cio­nes. En principio no hay re­s­tri­c­cio­nes en cuanto a la creación y pu­bli­ca­ción de imágenes en el Docker Hub y esto es lo que conlleva el riesgo de in­tro­du­cir código maligno en un sistema por la descarga de una imagen. Por ello, antes del de­s­plie­gue de una apli­ca­ción, los usuarios de Docker siempre deberían ase­gu­rar­se de que el código completo su­mi­ni­s­tra­do por una imagen para ejecutar co­n­te­ne­do­res proceda de una fuente fiable.

Docker ofrece un programa de ce­r­ti­fi­ca­ción con la cual se pueden examinar y ga­la­r­do­nar a pro­vee­do­res de in­frae­s­tru­c­tu­ra, de co­n­te­ne­do­res y de ex­te­n­sio­nes. Con este programa de ce­r­ti­fi­ca­ción, Docker quiere facilitar a los de­sa­rro­lla­do­res la creación de cadenas de su­mi­ni­s­tro de software seguras para sus proyectos.

Además de un aumento de la seguridad para los usuarios, los ce­r­ti­fi­ca­dos de Docker aspiran a ofrecer a los de­sa­rro­lla­do­res de software la po­si­bi­li­dad de destacar con sus proyectos entre los numerosos recursos di­s­po­ni­bles. Entre otros aspectos, las imágenes ce­r­ti­fi­ca­das se cla­si­fi­can mejor en los re­su­l­ta­dos de búsqueda de Docker Hub y se etiquetan con la insignia “Verified Publisher”.