Docker Swarm es una herramienta software que permite ejecutar los contenedores en una granja de nodos, esto implica uno o varios balanceadores de carga implementados en uno o varios nodos maestros y los nodos que prestan el servicio, implementados en nodos trabajadores. Los contenedores que se ejecutan en modo Swarm se les denomina en ocasiones como modo enjambre. 

La referencia a que pueda existir uno varios nodos maestros es debido a que debe haber al menos un nodo maestro, pero podría haber más de uno sin que esto sea un conflicto. 

Ejecutar Docker en modo Swarm permite gestionar varios clusters de manera descentralizada. Esto es una orquestación de contenedores los cuales no tienen por qué estar situados en la misma máquina física ni virtual. Crea así una independencia del sistema que aloja los contenedores, aumentando la seguridad ante pérdida del servicio si se distribuye los nodos en distintas máquinas. 

Docker Swarm se basa en una arquitectura maestro-esclavo (manager-worker). Cada enjambre está formado al menos por un nodo maestro (también llamado administrador o manager) y tantos nodos esclavos (llamados trabajadores o workers) como se desee. El maestro de Swarm es responsable de la gestión del clúster y la delegación de tareas, el esclavo se encarga de ejecutar dichas tareas. 

Existen tres conceptos que se deben diferenciar: servicio, aplicación y tarea. Los servicios definidos para Docker Swarm pueden contener varias tareas o una única. Las tareas hacen referencia a las réplicas de un mismo servicio y puede existir varias tareas de un mismo servicio. El encargado de esta distribución de tareas entre los nodos como ya se ha mencionado es el manager del enjambre. 

Las aplicaciones hacen referencia a los distintos softwares que puede contener un mismo contenedor que ejecuta una imagen específica de Docker.   

Aquí os dejamos una imagen que puede ilustrar las diferencias entre estos conceptos es la siguiente: 

Se distinguen dos maneras de trabajar con Docker Swarm en cuanto a cómo es la disponibilidad de las réplicas de los servicios definidos: 

• Servicios globales: Swarm ejecutará una tarea en todos y cada uno de los nodos del clúster que cumpla con las restricciones establecidas como la ubicación del servicio o recursos.  

• Servicios replicados: se especifica el número de tareas idénticas que se desea ejecutar. Swarm creará tantas réplicas de la tarea especificada como se ha determinado. Por ejemplo, si creamos un servicio con dos réplicas, Swarm creará dos tareas que alojará en los nodos del enjambre. 

La imagen anterior muestra cómo existe un servicio replicado con dos réplicas, alojado en dos nodos distintos. Existe también un servicio global, de este segundo se encuentra una réplica en cada nodo disponible. 

La manera de trabajar con un servicio global o un servicio replicado se establece mediante el número de réplicas a ejecutar de un servicio o indicando que se desea ejecutar el servicio en el modo global. Se puede indicar mediante las sentencias del Docker CLI o mediante el docker-compose.yml 

Para el ejemplo de servicios replicados ambos ejemplos serían los siguientes: 

• A través de la ejecución iniciada con un comando similar al siguiente: 

• Mediante docker-compose.yml: 

Se observa que en ambos ejemplos las réplicas establecidas a generar son tres del servicio my_website. 

Por otro lado, siguiendo este mismo ejemplo, pero en el caso de servicios globales sería de la siguiente manera: 

• Inicio del servicio mediante un comando parecido al siguiente: 

• Mediante docker-compose.yaml 

En este ejemplo el servicio my_website se está ejecutando en modo global, es decir una réplica por cada nodo disponible. 

Los servicios pueden ser accesibles por cualquier nodo del swarm, que como se verá más adelante, usa una red ovelay interna (Ingress network) que conecta todos sus nodos y la petición llega al nodo donde se esté ejecutando el servicio. 

Cada servicio se registra automáticamente en un DNS interno del Swarm. Si un servicio está replicado en varios nodos el nodo gestor balancea las peticiones usando el DNS. Por ejemplo, si hay tres réplicas de my_website, el DNS podría tener registrado lo siguiente: 

my_website 172.17.0.5 

my_website 172.17.0.6 

my_website 172.17.0.7 

Y cada vez que se pide el servicio el DNS responde usando las tres direcciones de forma circular. 

Si hay varios nodos gestores funcionan en modo Activo-Pasivo, uno es el “leader” y los demás están de respaldo. 

Características de Docker Swarm 

Docker Swarm se caracteriza por las siguientes ventajas principalmente: 

• Se encuentra integrado con la API Docker Engine. 
• Se organiza de manera jerárquica muy simple, existen únicamente dos roles. El rol de worker y el rol de manager. Los managers pueden actuar también como workers. 
• Redistribución de las cargas de trabajo si algún nodo falla asegurando una alta disponibilidad. 
• Administración de los grupos de contenedores, ofreciendo la posibilidad de agregar, eliminar, balancear la carga entre ellos, etc. 
• Funcionalidades de escalado manual, permitiendo aumentar y disminuir recursos según necesidad, y rolling updates (gestión de actualizaciones sobre los servicios) integrado. 
• No es necesaria ninguna instalación extra para tenerlo disponible con Docker. 

¿Deberías plantearte implementar Docker en tus proyectos?

Desde Making Science pensamos que es una muy buena elección si se trata de un entorno de pruebas en el cual se compone de varios microservicios. La opción es atractiva debido a que se pueden configurar las redes de cada microservicio y las características de cada uno de ellos de manera sencilla, pero, debido a sus similitudes con Kubernetes, hace que en entorno de producción la adopción de Kubernetes sea muy superior.

Los orígenes de Docker residen en la empresa antes llamada dotCloud Inc, esta misma debe tanto su éxito actual a la tecnología Docker que el nombre en este momento de la compañía es Docker Inc. 

El software de Docker nace como un proyecto interno en dotCloud que se dedicaba principalmente a ofrecer un servicio PaaS (Platform-as-a-Service). Con la intención de mejorar sus servicios los ingenieros de la compañía trabajaban en el lanzamiento de tareas desplegadas sobre el kernel de Linux que incluyesen funcionalidades de LXC (LinuX Containers) y cgroups.

Para poder entender esto puede surgir la siguiente pregunta, ¿qué son los cgroups y LXC? Primero vamos con la parte de los cgroups y después una introducción de LXC con similitudes o diferencias con la tecnología Docker. 

Los cgroups de GNU/Linux o grupos de control, son una característica del kernel Linux que permite que los procesos se organicen en grupos jerárquicos. El objetivo de agrupar los procesos de esta manera es limitar y monitorizar el uso que hacen estos procesos de los recursos. Con la ayuda de los cgroups, cada proceso corre en su propio espacio del kernel y de la memoria pudiendo así limitar los recursos de los que dispone.

LXC, el antecesor de Docker

LXC es previo a Docker pero comparten varias similitudes. LXC es una plataforma de contenedores open source que proporciona un conjunto de herramientas, plantillas, bibliotecas y enlaces entre lenguajes. Ofrece un entorno de virtualización que puede instalarse en varios sistemas basados en Linux.

Como se comentaba LXC es el antecesor de Docker, pero estos ahora encuentran diferencias entre sí como las siguientes: 

• La herramienta Docker no limita su instalación únicamente a los sistemas operativos basados en Linux, ya que puede ser instalado en otros sistemas operativos como Windows o Mac OS.
• LXC es un contenedor de sistema operativo, mientras que Docker es un contenedor de aplicaciones; esto se refleja en que cada contenedor LXC suele tener varios servicios ejecutándose y en cada contenedor de Docker se suele aislar una única aplicación. De este modo, un contenedor LXC se comporta como un sistema operativo funcional, por ello todos los contenedores incluyen como mínimo todas las funcionalidades básicas de un sistema operativo. Por el contrario, Docker solo virtualiza lo necesario haciendo que este sea extremadamente ligero. Debido a sus características es más ligero la ejecución de un contenedor Docker que un contenedor  LXC. 
• Una ventaja de Docker es que, debido a una gran comunidad a la que se le permite alojar sus imágenes de Docker en un repositorio de manera gratuita y a las grandes distribuidoras que publican imágenes oficiales, es muy sencillo obtener imágenes pre-configuradas para distintas aplicaciones o uso. Las imágenes LXC también pueden compartirse de igual manera en un repositorio pero su uso no es tan extendido como el de DockerHub, el cuál es gratuito y de uso muy sencillo para almacenar, compartir u obtener imágenes. 

 Imagen : Diferencias entre Docker y LXC  

Continuando con la historia de los orígenes de Docker, fue en 2013 cuando la empresa dotCloud presentó de manera pública la herramienta Docker y, ante la buena acogida de la comunidad tecnológica, se definió como un proyecto open source. Esto significa que cualquiera podría, de manera gratuita, descargar, ejecutar y modificar el código de Docker. Al igual que en otros proyectos open source, que se expusiese el código y se ofreciera la posibilidad de mejorarlo hizo que Docker obtuviera una gran fama y ventajas. 

En cuanto al uso de Docker la empresa Apium Hub nos ofrece los siguientes datos: 

• 2/3 de las empresas que prueban Docker, lo adoptan. La mayoría de las compañías que adoptaron Docker ya lo hicieron dentro de los 30 días posteriores al uso inicial de la producción, y casi todos los restantes se convierten dentro de los 60 días. 
• La adopción de Docker real aumentó un 30% en un año. 
• PHP, Ruby, Java y Node son los principales frameworks de programación utilizados en contenedores.
   

¿Qué es Docker? 

La tecnología Docker usa el kernel de Linux y las funciones que este ofrece, como pueden ser los cgroups y namespaces, para segregar los procesos.  

Los namespaces de GNU/Linux permiten encapsular recursos globales del sistema de forma aislada, evitando que puedan interferir con procesos que estén fuera del namespace. Los cambios en el recurso global son visibles para otros procesos que son miembros del namespace, pero son invisibles para otros procesos fuera del mismo namespace. Ejemplo de uso de los namespace es la configuración de los network namespace que nos permiten aislar la configuración de red, IP, firewall o más elementos similares entre distintos namespaces. 

Es la combinación del uso de cgropus y namespaces lo que enmarca la definición de un contenedor en concreto, produciendo que cada uno de los contenedores se puedan ejecutar de manera independiente. Uno de los propósitos de los contenedores Docker es lograr esta independencia. Esto aporta la capacidad de ejecutar varios procesos y aplicaciones por separado mejorando el uso de su infraestructura y, al mismo tiempo, conservando la seguridad, como si se tratase de sistemas aislados, como se observa en la siguiente imagen: Estructura simbólica de la herramienta Docker. 

Imagen : Estructura simbólica de la herramienta  Docker 

Docker vs máquinas virtuales 

Las herramientas del contenedor basado en kernel Linux, como Docker, ofrecen un modelo de implementación basado en imágenes. Esto permite compartir una aplicación, o un conjunto de servicios, con todas sus dependencias en varios entornos. Docker también automatiza la implementación de la aplicación (o conjuntos combinados de procesos que constituyen una aplicación) en este entorno de contenedores. Es decir, otra de las ventajas que se suma a la independencia y aislamiento es la gran portabilidad de su uso mediante la posibilidad de compartir imágenes con control de versiones. La distribución de las imágenes de estos contenedores es similar a la de las imágenes de las VMs (Virtual Machine);  la diferencia fundamental es que no hay que virtualizar todo el sistema operativo si no solo lo necesario para ejecutar la aplicación, esta característica lo hace extremadamente más ligero. 

 Imagen : Estructura de una máquina virtual frente a un contenedor Docker 

La ejecución de un contenedor Docker está asociado a una máquina, ya sea virtual o física. Esta máquina puede ser que sea accedida por distintos usuarios, por ello se debe limitar los permisos de la ejecución de Docker a únicamente los usuarios necesarios para evitar creaciones o destrucciones de los contenedores, volúmenes o más elementos de Docker que no sean correctas.

Conclusión

¿Deberías plantearte implementar Docker en tus proyectos? Creemos que es una muy buena elección.

Sin analizar en profundidad, Docker nos ofrece varias ventajas sobre cómo definir la infraestructura como código, lo que nos proporciona portabilidad a cualquier entorno e histórico de cambios. 

Al definir ese código en un repositorio permite observar su evolución y cambios. Esto facilita el trabajo de «vuelta atrás» en caso de que se produzcan errores en las nuevas definiciones del código que controlan la infraestructura. Todo esto acelera y agiliza los cambios de infraestructura para que los posibles errores tengan la mínima repercusión en un posible entorno de producción.

Por otro lado, la gran portabilidad de la imágenes y código permiten exportar y compartir entre los desarrolladores un mismo entorno de trabajo, combinado con el aislamiento que ofrecen los contenedores docker para que no interfiera quien o donde se esté ejecutando.

Además de todo ello, existe una gran comunidad abierta e imágenes de Docker oficiales de las aplicaciones más utilizadas, que permiten tenerlas desplegadas en minutos, así como imágenes de la comunidad para todo tipo de aplicaciones y usos.