docker swarm join

Swarm Este comando funciona con el orquestador de Swarm.

Descripción

Une un nodo a un swarm. El nodo se une como un nodo administrador (manager) o un nodo trabajador (worker) según el token que pases con la opción --token. Si pasas un token de administrador, el nodo se une como administrador. Si pasas un token de trabajador, el nodo se une como trabajador.

Opciones

Ejemplos

Unir un nodo al swarm como administrador

El siguiente ejemplo muestra cómo unir un nodo administrador utilizando un token de administrador.

$ docker swarm join --token SWMTKN-1-aabbccdd00112233aabbccdd00112233aabbccdd00112233aa-aabbccdd00112233... 192.168.99.121:2377
This node joined a swarm as a manager.

$ docker node ls
ID                           HOSTNAME  STATUS  AVAILABILITY  MANAGER STATUS
dkp8vy1dq1kxleu9g4u78tlag *  manager2  Ready   Active        Reachable
dvfxp4zseq4s0rih1selh0d20    manager1  Ready   Active        Leader

Un clúster debe tener un máximo de 3 a 7 administradores, ya que la mayoría de ellos debe estar disponible para que el clúster funcione. Los nodos que no participen en este quórum de administración deben unirse como trabajadores. Los administradores deben ser hosts estables con direcciones IP estáticas.

Unir un nodo al swarm como trabajador

El siguiente ejemplo muestra cómo unir un nodo trabajador utilizando un token de trabajador.

$ docker swarm join --token SWMTKN-1-aabbccdd00112233aabbccdd00112233aabbccdd00112233aa-aabbccdd00112233... 192.168.99.121:2377
This node joined a swarm as a worker.

$ docker node ls
ID                           HOSTNAME  STATUS  AVAILABILITY  MANAGER STATUS
7ln70fl22uw2dvjn2ft53m3q5    worker2   Ready   Active
dkp8vy1dq1kxleu9g4u78tlag    worker1   Ready   Active        Reachable
dvfxp4zseq4s0rih1selh0d20 *  manager1  Ready   Active        Leader

Valor de --listen-addr

Si el nodo es un administrador, escuchará el tráfico entrante del administrador de swarm en esta dirección. El valor predeterminado es escuchar en 0.0.0.0:2377. También es posible especificar una interfaz de red para escuchar en la dirección de esa interfaz; por ejemplo, --listen-addr eth0:2377.

Especificar un puerto es opcional. Si el valor es una dirección IP simple o un nombre de interfaz, se utilizará el puerto predeterminado 2377.

Por lo general, esta opción no es necesaria al unirse a un swarm existente.

Valor de --advertise-addr

Esta opción especifica la dirección que se anunciará a otros miembros del swarm para el acceso a la API. Si no se especifica, Docker comprobará si el sistema tiene una única dirección IP y la utilizará junto con el puerto de escucha (consulta --listen-addr). Si el sistema tiene múltiples direcciones IP, se debe especificar --advertise-addr para elegir la dirección correcta para la comunicación entre administradores y la red superpuesta (overlay).

También es posible especificar una interfaz de red para anunciar la dirección de esa interfaz; por ejemplo, --advertise-addr eth0:2377.

Especificar un puerto es opcional. Si el valor es una dirección IP simple o un nombre de interfaz, se utilizará el puerto predeterminado 2377.

Por lo general, esta opción no es necesaria al unirse a un swarm existente. Si vas a unir nuevos nodos a través de un equilibrador de carga, debes utilizar esta opción para asegurarte de que el nodo anuncie su propia dirección IP y no la del equilibrador de carga.

--data-path-addr

Esta opción especifica la dirección que los controladores de red de alcance global publicarán hacia otros nodos para llegar a los contenedores que se ejecutan en este nodo. Al usar este parámetro, es posible separar el tráfico de datos del contenedor del tráfico de administración del clúster. Si no se especifica, Docker utilizará la misma dirección IP o interfaz configurada para la dirección anunciada.

Cadena --token

Valor secreto requerido para que los nodos se unan al swarm

--availability

Esta opción especifica la disponibilidad del nodo en el momento en que se une a un nodo maestro. Los valores posibles son active, pause o drain.

Esta opción es útil en ciertas situaciones. Por ejemplo, es posible que un clúster prefiera tener nodos administradores dedicados que no actúen como nodos trabajadores. Esto se puede lograr pasando --availability=drain a docker swarm join.