Despliegue en un cluster

1. Objetivo

Hasta ahora, todos los despliegues se han realizado utilizando la máquina local como host de los contenedores. Cuando hablamos de despliegue, el registro permite poner a disposición de máquinas exteriores las imágenes creadas en una máquina dada, pero no impide que estas máquinas exteriores después de conectarse al registro para recuperar la imagen, instancien los contenedores correspondientes de manera local. El funcionamiento sigue siendo unitario y finalmente, no muy diferente de un despliegue sobre la máquina que ha servido para crear la imagen.

En el presente capítulo, vamos a estudiar los medios de desacoplar esta lógica y separar la máquina que controla el despliegue de la o las máquinas que van a llevar de manera efectiva los contenedores. El objetivo principal de este desacoplamiento es poder llegar fácilmente a varias máquinas para la segunda parte, y de esta manera poder extender fácilmente su capacidad de despliegue de contenedores, añadiendo recursos de hardware de manera transparente respecto al despliegue. En resumen, el objetivo del clustering de los contenedores es permitir el despliegue de contenedores sobre un conjunto de máquinas que se comportan como una única y enorme entidad host de contenedores.

Otro objetivo que está muy relacionado, es desarrollar un número variable...

1. Funcionamiento resumido de Swarm

Aunque se trate de una herramienta ya muy sofisticada sobre la que podríamos escribir centenares de páginas, se puede implementar un cluster Swarm y explotar con muy pocos conocimientos, que vamos a resumir aquí.

En primer lugar, un cluster Swarm divide las máquinas que gestiona (se habla de nodos) en dos categorías, a saber, los agentes y los managers.

Los agentes son nodos de pura ejecución: su trabajo consiste en encargarse de los contenedores, pero ellos no deciden qué contenedores ni las condiciones de puesta en marcha o escalabilidad.

Los nodos administradores son los que centralizan esta orquestación y justamente van a decidir qué contenedor se arranca en qué demonio, con qué método de reparto de trabajo, etc. En resumen, son la parte inteligente de la red. Sin embargo, por defecto, un nodo administrador también es un agente, es decir puede hacer funcionar los contenedores como el resto. Esta elección tiene sentido visto que la carga de orquestación es tan baja y que decidir un nodo solo para esta tarea, sería un desperdicio de recursos.

Cuando se inicializa un cluster Swarm en una máquina (con un comando que se mostrará más adelante), el demonio se convierte automáticamente en un manager, y proporciona dos tokens que permiten, siempre que la máquina tenga acceso a la red de la primera, transformar el demonio de una segunda máquina en un manager asociado, o bien en un agente al servicio del primer manager. En nuestro ejemplo, crearemos un cluster muy sencillo con un manager y dos agentes.

Una vez que el cluster se haya implementado, aparece el conjunto de los demonios desde el punto de vista exterior, como un único demonio con una capacidad más grande. Para mostrar esto, una vez que se haya formado...

1. Aspectos principales de los servicios

Para realizar este despliegue, en primer lugar va a ser necesario explicar rápidamente los conceptos de servicios, tareas y otras nociones relacionadas con la utilización de Swarm. De nuevo, el objetivo es dar un barniz mínimo para que el lector de este libro tenga unas nociones sobre conceptos. El siguiente diagrama explica con una imagen y pocas frases, la manera en la que Swarm permite el despliegue de aplicaciones con ayuda de "servicios" (en el sentido en que se han definido en el archivo Docker Compose).

Para simplificar el enlace con los comandos Docker, utilizaremos mayoritariamente las palabras en inglés para describir todas las relaciones del esquema anterior:

1. ¿Qué sucede en su interior?

En primer lugar, en el ejemplo que se ha mostrado anteriormente, conviene volver sobre varios puntos que facilitan la comprensión de lo que realmente ha pasado.

a. Comandos de diagnóstico

Cuando se lanza el stack, es posible seguir el estado de los servicios, utilizando el comando docker stack ps, seguido del nombre del stack destino (la lista se puede encontrar con el comando docker stack ls). La siguiente visualización se corresponde, por ejemplo, con el estado al cabo de algunos segundos, con los servicios que han alcanzado su estado Running (que se están ejecutando), mientras que otros todavía están en el estado Preparing (en preparación, es decir en descarga o en ejecución):

Cuando todo está listo, la visualización pasa a algo parecido a lo siguiente:

Y cuando el escalado ha terminado, naturalmente encontramos tareas adicionales. La columna NODE nos permite ver en qué nodo se han asignado, sin tener que conectarse a la máquina como hemos hecho para facilitar la comprensión:

Más allá del stack, también es posible observar precisamente los servicios con el comando docker service ls, que devolverá globalmente lo mismo en caso de un despliegue de un stack único, pero con información diferente:

Una vez que se ha localizado un servicio a través de su identificador o nombre, hay otros comandos accesibles como docker service ps, que permite recuperar la información de instanciación del servicio:

El comando docker service inspect va a entrar mucho más en detalle, tradicionalmente se usará con un grep o como mínimo con un head o un tail para filtrar la visualización.

Desde las versiones más recientes de Docker, también es posible consultar los logs remotos, utilizando el comando docker service logs, como se muestra a continuación:

En resumen, como se prometió, es posible hacer casi todo lo necesario para mantener la aplicación en condiciones operativas desde un cliente Docker exterior. Solo los administradores...