Gérer les nœuds dans un swarm
Dans le cadre du cycle de vie de gestion du swarm, vous pourriez avoir besoin de :
Lister les nœuds
Pour voir une liste des nœuds dans le swarm, exécutez docker node ls
depuis un nœud gestionnaire :
$ docker node ls
ID HOSTNAME STATUS AVAILABILITY MANAGER STATUS
46aqrk4e473hjbt745z53cr3t node-5 Ready Active Reachable
61pi3d91s0w3b90ijw3deeb2q node-4 Ready Active Reachable
a5b2m3oghd48m8eu391pefq5u node-3 Ready Active
e7p8btxeu3ioshyuj6lxiv6g0 node-2 Ready Active
ehkv3bcimagdese79dn78otj5 * node-1 Ready Active Leader
La colonne AVAILABILITY
montre si le planificateur peut ou non assigner des tâches au
nœud :
Active
signifie que le planificateur peut assigner des tâches au nœud.Pause
signifie que le planificateur n'assigne pas de nouvelles tâches au nœud, mais les tâches existantes continuent à s'exécuter.Drain
signifie que le planificateur n'assigne pas de nouvelles tâches au nœud. Le planificateur arrête toutes les tâches existantes et les programme sur un nœud disponible.
La colonne MANAGER STATUS
montre la participation du nœud au consensus Raft :
- Aucune valeur indique un nœud travailleur qui ne participe pas à la gestion du swarm.
Leader
signifie que le nœud est le nœud gestionnaire principal qui prend toutes les décisions de gestion et d'orchestration du swarm pour le swarm.Reachable
signifie que le nœud est un nœud gestionnaire participant au quorum de consensus Raft. Si le nœud leader devient indisponible, le nœud est éligible pour l'élection comme nouveau leader.Unavailable
signifie que le nœud est un gestionnaire qui ne peut pas communiquer avec d'autres gestionnaires. Si un nœud gestionnaire devient indisponible, vous devriez soit joindre un nouveau nœud gestionnaire au swarm soit promouvoir un nœud travailleur pour être un gestionnaire.
Pour plus d'informations sur l'administration swarm, référez-vous au Guide d'administration Swarm.
Inspecter un nœud individuel
Vous pouvez exécuter docker node inspect <NODE-ID>
sur un nœud gestionnaire pour voir les
détails d'un nœud individuel. La sortie par défaut est au format JSON, mais vous pouvez
passer le flag --pretty
pour imprimer les résultats dans un format lisible par l'homme. Par exemple :
$ docker node inspect self --pretty
ID: ehkv3bcimagdese79dn78otj5
Hostname: node-1
Joined at: 2016-06-16 22:52:44.9910662 +0000 utc
Status:
State: Ready
Availability: Active
Manager Status:
Address: 172.17.0.2:2377
Raft Status: Reachable
Leader: Yes
Platform:
Operating System: linux
Architecture: x86_64
Resources:
CPUs: 2
Memory: 1.954 GiB
Plugins:
Network: overlay, host, bridge, overlay, null
Volume: local
Engine Version: 1.12.0-dev
Mettre à jour un nœud
Vous pouvez modifier les attributs d'un nœud pour :
- Changer la disponibilité du nœud
- Ajouter ou supprimer des métadonnées d'étiquette
- Changer le rôle d'un nœud
Changer la disponibilité du nœud
Changer la disponibilité du nœud vous permet de :
- Drainer un nœud gestionnaire pour qu'il effectue seulement des tâches de gestion swarm et soit indisponible pour l'assignation de tâches.
- Drainer un nœud pour pouvoir le mettre hors service pour maintenance.
- Mettre en pause un nœud pour qu'il ne puisse pas recevoir de nouvelles tâches.
- Restaurer le statut de disponibilité des nœuds indisponibles ou en pause.
Par exemple, pour changer un nœud gestionnaire vers la disponibilité Drain
:
$ docker node update --availability drain node-1
node-1
Voir lister les nœuds pour les descriptions des différentes options de disponibilité.
Add or remove label metadata
Node labels provide a flexible method of node organization. You can also use node labels in service constraints. Apply constraints when you create a service to limit the nodes where the scheduler assigns tasks for the service.
Run docker node update --label-add
on a manager node to add label metadata to
a node. The --label-add
flag supports either a <key>
or a <key>=<value>
pair.
Pass the --label-add
flag once for each node label you want to add:
$ docker node update --label-add foo --label-add bar=baz node-1
node-1
The labels you set for nodes using docker node update
apply only to the node
entity within the swarm. Do not confuse them with the Docker daemon labels for
dockerd.
Therefore, node labels can be used to limit critical tasks to nodes that meet certain requirements. For example, schedule only on machines where special workloads should be run, such as machines that meet PCI-SS compliance.
A compromised worker could not compromise these special workloads because it cannot change node labels.
Engine labels, however, are still useful because some features that do not affect secure orchestration of containers might be better off set in a decentralized manner. For instance, an engine could have a label to indicate that it has a certain type of disk device, which may not be relevant to security directly. These labels are more easily "trusted" by the swarm orchestrator.
Refer to the docker service create
CLI reference
for more information about service constraints.
Promote or demote a node
You can promote a worker node to the manager role. This is useful when a manager node becomes unavailable or if you want to take a manager offline for maintenance. Similarly, you can demote a manager node to the worker role.
NoteRegardless of your reason to promote or demote a node, you must always maintain a quorum of manager nodes in the swarm. For more information refer to the Swarm administration guide.
To promote a node or set of nodes, run docker node promote
from a manager
node:
$ docker node promote node-3 node-2
Node node-3 promoted to a manager in the swarm.
Node node-2 promoted to a manager in the swarm.
To demote a node or set of nodes, run docker node demote
from a manager node:
$ docker node demote node-3 node-2
Manager node-3 demoted in the swarm.
Manager node-2 demoted in the swarm.
docker node promote
and docker node demote
are convenience commands for
docker node update --role manager
and docker node update --role worker
respectively.
Install plugins on swarm nodes
If your swarm service relies on one or more
plugins, these plugins need to be available on
every node where the service could potentially be deployed. You can manually
install the plugin on each node or script the installation. You can also deploy
the plugin in a similar way as a global service using the Docker API, by specifying
a PluginSpec
instead of a ContainerSpec
.
NoteThere is currently no way to deploy a plugin to a swarm using the Docker CLI or Docker Compose. In addition, it is not possible to install plugins from a private repository.
The
PluginSpec
is defined by the plugin developer. To add the plugin to all Docker nodes, use
the
service/create
API, passing
the PluginSpec
JSON defined in the TaskTemplate
.
Leave the swarm
Run the docker swarm leave
command on a node to remove it from the swarm.
For example to leave the swarm on a worker node:
$ docker swarm leave
Node left the swarm.
When a node leaves the swarm, Docker Engine stops running in Swarm mode. The orchestrator no longer schedules tasks to the node.
If the node is a manager node, you receive a warning about maintaining the
quorum. To override the warning, pass the --force
flag. If the last manager
node leaves the swarm, the swarm becomes unavailable requiring you to take
disaster recovery measures.
For information about maintaining a quorum and disaster recovery, refer to the Swarm administration guide.
After a node leaves the swarm, you can run docker node rm
on a
manager node to remove the node from the node list.
For instance:
$ docker node rm node-2