Escalar y actualizar un servicio de un cluster de Docker Swarm

Una vez que ya hemos creado un cluster de nodos con Docker Swarm y hemos desplegado algunos servicios ya sea directamente mediante comandos para crear servicios o mediante un stack con un archivo similar a un Docker Compose al cabo de un tiempo necesitaremos hacer otras operaciones. Dos de esas operaciónes básicas son escalar hacia arriba o hacia abajo un servicio cambiando el número de instancias de contenedores desplegadas o actualizar la imagen que utilizan los servicios por otra diferente posiblemente más nueva.

En la documentación de Docker están detallados y comentados los comandos para escalar un servicio. Por ejemplo, en el cluster de ejemplo formado por tres nodos, uno con el rol de manager y otros dos como worker, ejecutándose en VirtualBox y desplegando un servicio para el servidor nginx con inicialmente una réplica o instancia podemos escalar el servicio para que se cree alguna instancia o contenedor más del servicio con el siguiente comando docker service scale.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

#!/usr/bin/env bash

#export MACHINE_STORAGE_PATH="/run/media/picodotdev/BMOVE ROJO/docker-machine/"
eval $(docker-machine env node-01)

echo -e "\n# Nginx service tasks"
docker service ps nginx

echo -e "\n# Nginx service inspect"
docker service inspect --pretty nginx

docker service scale nginx=4

sleep 1m

echo -e "\n# Nginx service tasks"
docker service ps nginx

echo -e "\n# Nginx service inspect"
docker service inspect --pretty nginx

Al igual que cuando se crea un contenedor para un servicio en el cluster Docker Swarm si no se indica alguna restricción decidirá en qué nodos se crean las nuevas instancias o contenedores del servicio.

Por otro lado, una vez desplegados en un cluster algunos servicios llegará el momento en que queramos actualizar algún parámetro del servicio, uno de ellos será probablemente la imagen del servicio cuando se publique una nueva. En la página de documentación Aplicando actualizaciones a un servicio está explicada esta funcionalidad y los comandos junto con sus opciones que hay que utilizar.

En el ejemplo al crear el cluster se usa la última imagen de docker para nginx, en un entorno de producción es más recomendable establecer una versión en concreto para evitar que la imagen que se usa no varía desde que se prueba hasta que se despliega. El siguiente script actualiza la imagen a la versión nginx:1.10-alpine en todas las réplicas del servicio de nginx en el cluster.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

#!/usr/bin/env bash

#export MACHINE_STORAGE_PATH="/run/media/picodotdev/BMOVE ROJO/docker-machine/"
eval $(docker-machine env node-01)

echo -e "\n# Nginx service tasks"
docker service ps nginx

echo -e "\n# Nginx service inspect"
docker service inspect --pretty nginx

docker service update --image nginx:1.10-alpine nginx

sleep 1m

echo -e "\n# Nginx service tasks"
docker service ps nginx

echo -e "\n# Nginx service inspect"
docker service inspect --pretty nginx

Docker Swarm realiza el proceso de actualización siguiendo los siguientes pasos:

• Detiene el primer contenedor o tarea a actualizar.
• Programa la actualización del contenedor o tarea detenida.
• Inicia una nueva tarea actualizado.
• Si la tarea actualizada retorna su estado como RUNNING se espera un tiempo determinado y se inicia el proceso de actualización de una nueva tarea.
• Si, en cualquier momento durante la actualización, una tarea retorna su estado como FAILED, se detiene la actualización.

Por defecto, el planificador actualiza las tareas o contenedores del servicio de uno en uno. Con la opción --update-parallelism se especifica el número de tareas del servicio que se actualizan simultáneamente. La opción --update-delay especifica el tiempo de espera desde que se actualiza la tarea de un servicio y la siguiente. Se puede describir como una combinación de segundos, minutos o horas, de modo que 1m30s indica una espera de 1 minuto y 30 segundos.

En los archivos en formato YAML de los stacks de Docker Compose hay una sección en cada servicio en el que se indica el número de contenedores que se desea que esté formado el servicio así como las opciones de paralelismo y tiempo de espera entre actualización. Para actualizar el stack basta con hacer de nuevo el deploy, ya sea la imagen usada, el número de réplicas u otros parámetros.

1
2
3
4
5
6
7

...
deploy:
  replicas: 4
  update_config:
    parallelism: 1
    delay: 1m30s
...

El código fuente completo del ejemplo puedes descargarlo del repositorio de ejemplos de Blog Bitix alojado en GitHub.