El ecosistema Docker: las Docker tools más populares
En el transcurrir de unos pocos años, el nombre “Docker” se ha convertido prácticamente en sinónimo para la tecnología de contenedores de software. La empresa ha logrado revitalizar las funciones básicas del núcleo de Linux para la virtualización en el nivel del sistema operativo y, desarrollando un estándar propio, se consolidó como alternativa multiplataforma a la virtualización de hardware apoyada en hipervisores.
A continuación presentamos las extensiones para la plataforma más significativas y los proyectos de terceros más populares que están desarrollando herramientas de código abierto para Docker.
Extensiones a Docker y servicios online
Docker es hoy mucho más que una ligera plataforma para la gestión de contenedores de software. 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 su disposición diversas extensiones y servicios online 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 que fundamenta a 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 por líneas de comando y gestionar las imágenes, los archivos de Docker y los contenedores desde el terminal.
En nuestro tutorial de Docker para principiantes [detallamos el motor de Docker en profundidad.
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. Descargar una imagen pública —con el comando pull— no requiere abrir una cuenta. 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 suministrados por equipos de desarrollo y reconocidos proyectos open source ofrecidos en archivos de imágenes oficiales. Entre las imágenes de Docker más populares se cuentan el ligero 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 teams y afiliaciones de grupo.
Docker Machine
La Docker Machine hace posible instalar y administrar un host de Docker en casi cualquier infraestructura. La herramienta automatiza la implementación de Docker de forma que la instalación de hosts de Docker se simplifica de forma sustancial.
Con el nombre de “Docker host” o “Dockerized host” los desarrolladores designan al host virtual en donde se ejecuta el Docker Engine. Mientras que el motor de Docker siempre se ha podido ejecutar de forma nativa en todas las distribuciones Linux, cuando se quiso ampliar la familia con los sistemas macOs y Windows surgió la necesidad de una capa de abstracción en forma de una Docker Machine. Con el lanzamiento de la versión v1.12 esto ya no es necesario y, hoy en día, Docker también está disponible como proyecto multiplataforma para Mac y Windows. Con ello, el campo de aplicación principal de Docker Machine se ha desplazado a escenarios remotos y a la gestión de hosts de Docker en entornos cloud.
A la hora de gestionar un elevado número de nodos de Docker en una red o en infraestructuras en la nube como Amazon Web Services (AWS) o DigitalOcean, tarde o temprano es necesario recurrir a una Docker Machine. La herramienta reduce el trabajo ligado a la creación de nuevos hosts a un simple comando, “Docker-machine create”, y facilita la gestión de varios nodos desde el terminal. La Docker Machine pasa a encargarse de la creación de una SSL-PKI así como de la distribución de los certificados necesarios para la autenticación de los usuarios. En combinación con Docker Swarm, el software se utiliza para configurar clústeres Docker.
La Docker Machine suele utilizarse en el sistema local, donde de forma automatizada crea nuevos hosts, instala el Docker Engine y configura el programa de líneas de comando instalado localmente para el acceso remoto. Esto le permite al usuario comunicarse con los hosts en la nube a través del terminal del sistema local para ejecutar en él los comandos de Docker por control remoto.
Docker Swarm
Desde la versión 1.12, 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. Las versiones anteriores de la plataforma de contenedores tienen a su disposición la Docker tool Swarm como aplicación autónoma.
un clúster consiste en un conjunto de hosts Docker alojados en la infraestructura de un proveedor IaaS externo o en un centro de datos propio.
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
Compose es la solución de Docker para aplicaciones compuestas por varios contenedores interrelacionados (aplicaciones multicontenedor). Desarrollada inicialmente como fig por la compañía de software Orchard, esta ligera herramienta de orquestación ya forma parte del porfolio de Docker.
Docker Compose permite conectar varios contenedores y ejecutarlos con un único comando. Implementada en el lenguaje de scripts Python, 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 virtuales.
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 Cloud (antes Tutum)
A finales de 2015, Docker se apropia del servicio de despliegue de contenedores y de gestión Tutum y lo transforma en Docker-Cloud. Mientras que Docker hub funciona como repositorio central de imágenes, la nube de Docker provee una plataforma basada en la web mediante la cual se pueden crear, probar, supervisar y distribuir contenedores Docker en diversas infraestructuras.
La nube de Docker ofrece una integración nativa con todos los servicios Docker y se distingue por su compatibilidad con proveedores de servicios en la nube como Microsoft Azure, Amazon Web Services, DigitalOcean, IBM Softlayer, Packet.net o Google Container Engine. Los usuarios tienen también la posibilidad de conectar la nube de Docker con su propia infraestructura. Ahora bien, conviene no olvidar que la nube de Docker no ofrece servicios de alojamiento. Todos los recursos para nodos, servicios y lotes que se crean con la plataforma de despliegue han de ser suministrados por proveedores externos o por el propio centro de datos.
un lote es un conjunto formado por varios servicios Docker que juntos dan como resultado una aplicación.
La conexión nativa a proveedores consolidados de Infraestructura como Servicio (IaaS) ofrece al usuario la posibilidad de instalar aplicaciones en diferentes plataformas de alojamiento o de implementar arquitecturas híbridas en combinación con nodos locales. La gestión de nodos Docker distribuidos en diferentes infraestructuras se realiza de forma central en una interfaz gráfica de usuario: el panel de control de la nube de Docker o Docker Cloud Dashboard. En este panel, el usuario puede conectarse con su centro de datos o con un proveedor externo de hosting y crear nodos independientes o clústeres de nodos en función de sus necesidades.
en la Docker Cloud no se pueden implementar clústeres de nodos repartidos en diferentes proveedores externos.
Además de la instalación y el escalado multiplataforma de aplicaciones en la nube, esta plataforma de despliegue ofrece interfaces a diversos servidores de registro como el Docker Hub así como funciones automatizadas de build y test. En este vídeo realizado por el mismo equipo de desarrollo obtienes una idea general de las funcionalidades centrales y de los ámbitos de aplicación de la nube de Docker:
Docker Toolbox
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.
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 Mesosphere 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 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).
dependiente de la Linux Foundation (LF), la Cloud Native Computing Foundation (CNCF) nace en 2015 fruto de una cooperación entre la Fundación Linux y Google en la cual su proyecto Kubernetes pasó a manos de la CNCF en concepto de donación. La meta de la organización es impulsar la tecnología de contenedores en proyectos de código abierto. Además de Google, entre los integrantes de la CNCF también se incluyen Docker, Twitter, Huawei, Intel, Cisco, IBM, Univa y VMware.
Kubernetes 1.0 se lanzó a mediados de 2015 para utilizarse en sistemas productivos y se aplica en el contexto de la Google Contanier Engine (GKE). 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. El agente recibe las órdenes y los encargos del maestro y supervisa su ejecución en cada uno de los nodos.
- kube-proxy: junto al Container Engine y el agente kubelet, 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 balanceador de carga balancador de carga.
El siguiente gráfico muestra esquemáticamente la arquitectura maestro-esclavo en la que se fundamenta la plataforma de orquestación Kubernetes:
Kubernetes se puede completar con un gran número de herramientas y extensiones que amplían las funcionalidades de la plataforma. Entre las más conocidas se encuentran las herramientas de monitoring 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 una Java API con los cuales controlar Kubernetes remotamente.
Shipyard
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.
Panamax
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:
Panamax se presenta de la mano de CenturyLink como software open source distribuido con una licencia Apache-2. 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. El equipo de trabajo recomienda instalar CoreOs en el sistema local mediante Vagrant y Oracle Vitualbox. La estructura clásica de una instalación de Panamax en el sistema local sigue el siguiente esquema: en un ordenador local donde ya hay un sistema operativo instalado, el usuario instala CoreOs con ayuda del software de virtualización VirtualBox. A continuación el cliente Panamax se ejecuta en CoreOs como un contenedor Docker.
El software se desarrolló como cliente Docker especialmente para el ligero CoreOS. 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 demonio 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 demonio 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 laptop.
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. La herramienta, escrita en Go, se utiliza para cargar Builds (cada una de las fases en el desarrollo de un software nuevo) automáticamente desde repositorios Git como GitHub, GitLab o Bitbucket y ejecutarlas en contenedores Docker con la finalidad de testarlos. 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.
como “Continuous Integration” (CI, integración continua) se conoce al proceso en el desarrollo de software por el cual los componentes de software recién creados —los denominados builds, donde como verbo “build” significa “construir”— se agrupan y se ejecutan en entornos de prueba con periodicidad regular, normalmente una vez al día. Las aplicaciones complejas se desarrollan a menudo en equipos numerosos y la integración continua es una estrategia con la cual detectar y solucionar a tiempo errores de integración que pueden tener lugar en el trabajo conjunto de diferentes programadores. Drone ofrece a los desarrolladores de software la opción de realizar diferentes entornos de prueba con ayuda de contenedores Docker.
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:
OpenStack
Cuando se trata de construir y gestionar estructuras Cloud basadas en código abierto, OpenStack es la solución de software perfecta. Este sistema operativo cloud con licencia Apache nació en 2010 de la cooperación entre el proveedor de hosting norteamericano Rackspace y la NASA y cuenta con el apoyo de empresas como AT&T, SUSE, Canonical, HP, Intel Red Hat e IBM.
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 seis elementos fundamentales:
- Nova: el componente de computación principal de OpenStack recibe el sobrenombre de Nova y se podría considerar como el “cerebro” de esta arquitectura de software. Nova es responsable del control de todas las instancias de cálculo del sistema y permite iniciar máquinas virtuales (VM) basadas en imágenes, desplegarlas en entornos Cloud y gestionarlas en clústeres. Estas máquinas virtuales se pueden distribuir en tantos nodos como sea necesario.
Como unidad de control para redes de ordenadores en la nube (cloud computing fabric controller), Nova constituye el componente fundamental para servicios IaaS basados en OpenStack. Nova soporta diversas tecnologías hipervisor y de virtualización así como arquitecturas Bare Metal, en las cuales las máquinas virtuales se instalan directamente en el hardware. Normalmente se utilizan KVM, VMware, Xen, Hyper-V o LXC, el software contenerizador de Linux.
- Neutron: Antaño Quantum, Neutron 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.
- Cinder: 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.
- Keystone: 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.
- Glance: con este servicio, OpenStack permite almacenar y recuperar imágenes de máquinas virtuales. Nova utiliza las imágenes suministradas por Glance como modelo para generar instancias de máquinas virtuales.
- Swift: con este módulo Nova almacena objetos de datos desestructurados y los recupera a través de una API REST. Swift se distingue por una arquitectura redundante y escalable y una elevada tolerancia de errores.
Desde el lanzamiento Havanna de 2013, Nova ofrece un controlador de hipervisores para el Docker Engine que integra un cliente HTTP en la arquitectura de OpenStack con el fin de permitir la comunicación con la API interna de Docker a través de un Socket Unix.
El controlador Docker para Nova permite extraer imágenes desde Glance y cargarlas directamente en el sistema de archivos de Docker. Incluso es posible exportar imágenes utilizando el comando estándar Docker save desde Docker y guardarlas en Glance. En la wiki de OpenStack cuentas con un manual paso a paso con el que integrar Docker en una arquitectura OpenStack. Si esto no fuera suficiente, la fundación OpenStack ofrece en YouTube un taller de 90 minutos sobre la integración de Docker:
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.
Mesosphere DC/OS
DC/OS (Data Center Operating System) es un software de código libre desarrollado por Mesosphere Inc. 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 mesosphere.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 que, gracias a diversos componentes que simplifican la gestión de aplicaciones en sistemas repartidos, en la nube o en entornos on premises, amplía a Mesos con una extensa infraestructura. El siguiente vídeo del equipo de desarrolladores contiene una breve demostración de las funciones básicas de DC/OS:
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.
Docker Container como componente de una plataforma de infraestructura digital
Docker ha conseguido revolucionar por completo y en pocos años la industria informática. Con las estadísticas del proyecto en la mano, cuesta creer que el primer lanzamiento de la plataforma sucediera hace tan solo cuatro años, concretamente en marzo de 2013. Desde entonces, los usuarios de Docker han descargado más de ocho mil millones de imágenes y disponen de alrededor de medio millón de aplicaciones Docker diferentes en el repositorio. El proyecto se apoya en una comunidad de desarrolladores de cerca de tres mil cooperantes y hoy el ecosistema Docker abarca un número casi imposible de determinar de herramientas, ampliaciones y plataformas de software que hacen aún más eficiente el trabajo con la tecnología de contenedores. Según información propia, la tecnología desarrollada por Docker está hoy integrada en más de 100 mil proyectos externos. ¿En qué se fundamenta el éxito de la plataforma y de sus proyectos secundarios?
En tiempos de creciente interés por parte de los usuarios en la nube, crece también el valor de una aplicación como esta con tal grado de interconexión y expansión. Esta tendencia se refleja también en la forma como se desarrolla, se prueba y se ejecuta el software hoy en día. Para las empresas, las infraestructuras en la nube ofrecen una atractiva oportunidad para gestionar recursos informáticos de forma central y ofrecer acceso universal. Conceptos como Infraestructura como Servicio (Infrastructure-as-a-Service, IaaS) desligan los procesos en la empresa de los recursos de hardware de los propios centros de servidores y ofrecen la máxima flexibilidad y escalabilidad gracias a modelos de facturación personalizables.
Además de unas estrategias a propósito de la seguridad ante caídas, los centros de datos de los grandes proveedores de hosting proveen la alta disponibilidad y la continuidad del negocio que las pymes raramente pueden permitirse implementar en sus propias instalaciones. En este contexto, una técnica de virtualización ligera que permita convertir las aplicaciones en un formato portable y multiplataforma con la mínima sobrecarga y distribuirlas en infraestructuras cloud y entornos híbridos con un solo comando es la que se lleva el gato al agua. Como apenas ninguna otra tecnología, Docker utiliza la tendencia hacia la “Digital Infrastructure Platform”, la infraestructura como prestación de servicios basada en la nube.
El ecosistema Docker permite descomponer aplicaciones complejas en los llamados microservicios que luego se pueden repartir por diversos nodos conectados por API. De este modo, las empresas se aseguran no solo un plus en agilidad y flexibilidad, sino también en estabilidad. Las aplicaciones multicontenedor cuyos procesos se ejecutan en hosts diferentes en un sistema distribuido se pueden escalar de forma horizontal y las redundancias aportan seguridad a su gestión. La independencia de los microservicios encapsulados en contenedores contribuye, a todo esto, a que las actualizaciones y los parches afecten a partes concretas de una aplicación y nunca a la aplicación entera, de forma que los errores de software se puedan solucionar con mucha menos dificultad.
Sumado a lo anterior, la tecnología de contenedores también puede aportar funciones esenciales en el caso de una mudanza desde una infraestructura tradicional a una plataforma de infraestructura digital: la posibilidad de empaquetar aplicaciones con todas sus dependencias en contenedores portables y distribuirlas en cualquier plataforma (deployment) ayuda a los administradores a transformar sistemas antiguos (legacy applications) desde la tecnología estática a la dinámica.
a la vista de la creciente popularidad de las infraestructuras basadas en la nube, los entornos informáticos se pueden dividir en dos ámbitos fundamentales: los estáticos (Static IT) abarcan aplicaciones enterprise y backend operadas en infraestructuras clásicas como entornos on premises o en una nube privada. Sin embargo, cuando una empresa adquiere nuevos sistemas y aplicaciones, estos suelen ser implementados cada vez con más frecuencia en las plataformas cloud públicas para poder garantizar así la escalabilidad, flexibilidad e independencia geográfica más amplia posible. Para este ámbito se ha consolidado la denominación de entorno dinámico (Dynamic IT).
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.
Deployment
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.
Velocidad y performance
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.
DevOps y gestión de cambios
La digitalización y la tendencia al uso móvil de Internet han acelerado el ciclo vital de las aplicaciones de forma notoria. Las actualizaciones, los parches de seguridad y la solución de errores han de ser suministrados de inmediato, pero también los lanzamientos de las nuevas versiones de software se suceden cada vez a más velocidad.
Sin embargo, el despliegue de las actualizaciones sitúa a desarrolladores y administradores ante grandes retos, porque mientras que los fabricantes quieren ofrecer a sus clientes las nuevas funciones de una aplicación lo antes posible, los administradores padecen por el riesgo de caída que trae consigo cualquier cambio en la infraestructura informática y en los componentes de software apoyados en ella. Las estrategias para solucionar este tipo de dificultades toman el nombre de DevOps y nacen en el contexto de los DevOpsDays de 2009 en los que se presentan por primera vez a un público internacional las propuestas de mejora de los procesos con la vista puesta en la cooperación de los sectores de desarrollo (development) y gestión de la infraestructura de TI (operations).
El objetivo del DevOps es tanto mejorar la calidad de las nuevas versiones de software como acelerar el desarrollo, la entrega y la implementación gracias a una cooperación mucho más efectiva de todos los implicados y a la automatización continuada. Entre las tareas automatizables de DevOps se cuentan los procesos build del repositorio, los análisis estáticos y dinámicos del código y las pruebas de módulos, integración, sistema y rendimiento. La espina central del DevOps la constituyen hasta hoy las reflexiones a propósito de la integración continua (Continuous Integration, CI) y la entrega continua (Continuous Delivery, CD), dos campos centrales de aplicación de la plataforma Docker.
por Entrega Continua se entiende un principio para optimizar las entregas de software con ayuda de una diversidad de técnicas, procesos y herramientas. El eje central de tal concepto lo constituye la mecanización de la llamada deployment pipeline.
Docker ofrece opciones de integración para herramientas CI/CD consolidadas como Jenkins, Travis o Drone y permite cargar el código automáticamente desde el Hub de Docker o repositorios de control de versiones como GitHub, GitLab o Bitbucket. Es así como la plataforma de contenedores representa una base para flujos de trabajo DevOps en los cuales los desarrolladores pueden crear en común nuevos componentes para las aplicaciones y ejecutarlos en cualquier entorno de pruebas.
Docker soporta incluso entornos virtuales, on premises o en la nube, así como diversos sistemas operativos y distribuciones. En consecuencia, una de las principales ventajas de una arquitectura CI/CD basada en Docker es precisamente evitar a las empresas la ralentización derivada de las inconsistencias de entornos informáticos diferentes.
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. 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.
En conclusión: ¿cuáles son los pronósticos futuros de Docker?
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.