Gestión de nodos y servicios en Docker Swarm

Resumen

En el visualizer podemos ver que todas las tareas siguen corriendo en el "“worker 1"”, esto sucede porque el planificador de Docker Swarm no va a replanificar o redistribuir la carga de un servicio o de contenedores a menos que tenga que hacerlo; para solucionar esto, debemos forzar un redeployment o una actualización que se logra cambiando el valor de una variable que no sirva para nada.

docker service update -d --env-add UNA_VARIABLE=de-entorno --update-parallelism=0 app

docker service ps app

José Guillermo

student•

Disponibilidad de un nodo:

active. El nodo trabaja de forma coordinada con el Swarm y puede recibir nuevas tareas.
pause. El nodo deja de recibir nuevas tareas de manera indefinida, pero no desecha las que ya tiene corriendo.
drain. Le indica a Swarm que vacíe todas las tareas del nodo y lo mantenga así de manera indefinida. Si un servicio requiere un número definido de réplicas, Swarm redistribuye la respectiva carga del nodo drenado a otro nodo disponible.

Ver más en Administrar nodos de Swarm.

DAVID EDUARDO BAEZ SANCHEZ

student•

Entendido

docker node ls
docker  node inspect --pretty swarmwork02
docker node update --availability drain swarmwork02
docker node update --availability active swarmwork02
docker service update -d --env-add UNA_VARIABLE=de-entorno --update-parallelism=0 app
docker service rm app

![](

Javier G. Aguilar Melgar

student•

como para hacer un cluster con raspberry 🤭

Boris Vargas Paucara

student•

-- Como hacemos decirle que esto de aqui sacamelo

docker node ls
docker node inspect --pretty worker2

-- Le pasamos las replicas a los otros workers, es decir le quitamos replicas nuestro worker2

docker node update --availability drain worker2

-- Vamos a nuestro worker1 y observamos que tiene mucha carga

-- Vamos a nuestro manager, verificamos que nuetro worker2 esta en modo DRAIN y lo cambiamos a ACTIVE (observamos que no redistribuye las replicas a worker2)

docker node ls
docker node update --availability active worker2

-- Con este metodo podemos redistribuir, enviando las tareas a otros workers

docker service update -d --env-add UNA_VARIABLE=de-entorno --update-parallelism=0 app
docker service ps app

Edwin Garcia

student•

Porque no se debería aplicar lo de parallelism en un entorno productivo?

Jonatan Lazo

student•

Producirías downtime de tu aplicación

Edwin Garcia

student•

Gracias por la respuesta jonatan-lazo, probablemente no formulé bien mi pregunta, debido a que en el video Guido ya da de respuesta lo del dowtime, pero mi duda esta mas ligada a que se debe que el parallelismo crea el downtime, porque lo produce.

Oscar Adolfo Vargas López

student•

en este video hay un fallo y es que cuando pasamos un node a drain y queremos actualizar el servicio para balancear la carga debemos debemos pasar nuetro worker2 a active o si no cuando hagamos update queda todo en el worker 1

Pablo Aquino

student•

# inspect node
docker node ls
docker node inspect --pretty wrkr2

# mode drain (clean load) and mode availability
docker node update --availability drain wrkr2
docker node update --availability active wrkr2

# Force redistribution 
docker service update -d --env-add UNA_VARIABLE=de-entorno --update-parallelism=0 app
docker service ps app

Ricardo Etcheto

student•

me surgio una duda con el ejemplo que dio, en caso de que detectaramos que un nodo tiene problemas de conectividad, supongo que poderia ser de acceso a internet, entonces como podriamos hacer para mandar instrucciones a travez del nodo a docker swarm si justamente esta teniendo problemsa de conexion, es decir, si en la maquina donde esta corriendo ese nodo se corta internet entonces los comandos que ponga no le van a llegar al swarm, ya que justamente no tiene acceso a internet

Matias Gabriel Pierri

student•

Este ejemplo hace referencia a entornos productivos como podria ser que tenes un servicio desplegado en varias provincias de un mismo pais y hay un terremoto en provincia A digamos y redistribuis la carga a la provincia B

Gonzalo Amador Hernández

student•

lo que pasa la informacion esta en el manager de hecho justamente los comando

docker node ls
docker node inspect <node>
docker node update --availability drain <node>

se corren en el manager y no en el node, el estado de swarm lo manejan los managers

Gonzalo Amador Hernández

student•

Si no quieren agregar una variable de entorno nueva para redistribuir el servicio a los workers cada vez que activan uno node worker pueden usar nada mas:

docker service update app --force

en lugar de:

docker service update -d --env-add VAR=value app

Fredy Red Ramos Pomari

student•

docker node update --availability drain workder2
docker node update --availability active workder2
# Actualizar alguna variable de entorno para forzar la redistribución de contenedores
docker service update -d --env-add UNA_VARIABLE=de-entorno app

Fredy Red Ramos Pomari

student•

Eliminar containers

docker service rm app

Gonzalo Amador Hernández

student•

asi es, mas especificamente, los containers en los nodos de el servicio que queires eliminar

Francisco de Paula Ossa Pérez

student•

docker node ls docker node inspect --pretty swarmwork02 docker node update --availability drain swarmwork02 docker node update --availability active swarmwork02 docker service update -d --env-add UNA_VARIABLE=de-entorno --update-parallelism=0 app docker service ps app docker service rm app

Usuario anónimo

user•

Genial :) yo me di el trabajo de hacerlo en un entorno local