← swarm-exec.cloud-surfers.net

swarmexec_ docs

Utiliser le client — commandes, options, config & la TUI.

swarmexec vous donne docker exec -it, les logs, la redirection de ports et la gestion des volumes sur n'importe quel conteneur d'un Docker Swarm, depuis un seul terminal. Un petit agent par nœud (un service Swarm global) fait le travail sur son nœud ; le client demande au manager du Swarm quel nœud exécute votre cible, puis se connecte directement à l'agent de ce nœud via mTLS. Cette page documente le client.

1. Fonctionnement

Deux binaires, un seul protocole réseau :

• agent — s'exécute comme un service Swarm global (une tâche par nœud), monte le socket Docker de ce nœud et expose une API gRPC restreinte qui relaie exec / logs / redirection de port vers les conteneurs sur son propre nœud. Vous le déployez une fois avec swarmexec init.
• client (cette CLI) — s'exécute sur votre poste de travail. Il dialogue avec l'API du manager Swarm pour déterminer quel nœud exécute votre cible et l'id du conteneur, puis se connecte directement à l'agent de ce nœud sur le port 9443. Il n'y a pas de maillage agent-à-agent.

La connexion au manager utilise votre contexte Docker CLI (elle respecte donc --context, les bastions ssh://, mTLS, etc.). La connexion à l'agent est authentifiée par TLS mutuel, ou par un secret partagé avec un agent auto-signé — voir Authentification.

2. Installation

Nécessite Docker Engine 19.03 ou plus récent (API 1.40) sur le manager et sur chaque nœud. swarmexec refuse un démon plus ancien dès la connexion, en nommant les deux versions, plutôt que de se connecter puis d'échouer vue après vue. Deux fonctionnalités demandent un peu plus au démon du nœud : l'utilisation des ressources en direct et la vue des images par nœud veulent Docker 23.0 (API 1.41/1.42) ; en dessous elles restent vides et le disent, au lieu d'échouer.

Le client est un unique binaire statique. Récupérez le build de la dernière version pour votre plateforme :

Builds : linux-amd64, linux-arm64, darwin-arm64, darwin-amd64, windows-amd64. L'image de l'agent est publique sur Docker Hub sous logleio/swarmexec-agent.

3. Démarrage rapide

Pointez votre contexte Docker sur un manager Swarm, puis provisionnez les agents une seule fois. init crée un secret partagé, déploie l'agent sur chaque nœud en mode auto-signé et écrit une configuration client correspondante — de sorte que les autres commandes fonctionnent immédiatement.

Retirez à nouveau les agents avec swarmexec down (cela laisse votre configuration client intacte).

4. Sélecteurs de cible

exec, logs et port-forward prennent une cible comme premier argument. Elle est résolue dans cet ordre :

Ambiguïté. Un simple nom de service avec plusieurs répliques ne peut pas être résolu vers une seule tâche. exec vous invite à choisir dans une liste numérotée lorsqu'il est exécuté de façon interactive ; logs et port-forward ne demandent jamais — ils affichent la liste des candidats et se terminent. Levez l'ambiguïté avec un emplacement (web.0, web.1, …).

5. Configuration

Les paramètres proviennent de quatre couches, chacune l'emportant sur la précédente :

Une option ne l'emporte que lorsque vous la passez effectivement, de sorte qu'une valeur du fichier ou de l'environnement subsiste sauf si elle est explicitement remplacée.

Fichier de configuration

Le chemin par défaut est le premier de ceux-ci qui est défini :

1. $SWARMEXEC_CONFIG
2. $XDG_CONFIG_HOME/swarmexec/config.yaml
3. ~/.config/swarmexec/config.yaml

Remplacez-le avec --config <path>. Le fichier est en YAML ; un fichier manquant ne pose pas de problème, un fichier mal formé est une erreur. Il est écrit avec les droits 0600 (il peut contenir le secret partagé). Le fichier de log se trouve à côté par défaut — ~/.config/swarmexec/swarmexec.log — sauf si vous définissez --log-file. Clés :

La section logs: définit les valeurs par défaut de l'analyse et du filtrage des logs tenant compte du format ; les options --log-format / --min-level de la commande logs les remplacent :

Inspectez la configuration effective et fusionnée (secret masqué) avec :

addr-mode

hostname (par défaut) joint le nom d'hôte signalé par le nœud ; ip joint son adresse annoncée. Utilisez ip lorsque les noms d'hôte des nœuds ne sont pas résolvables depuis votre poste de travail — init écrit addr_mode: ip dans la configuration générée précisément pour cette raison. Le leader du swarm signale 0.0.0.0 pour lui-même ; le client récupère automatiquement sa véritable adresse depuis la liste des pairs raft.

Variables d'environnement

6. Authentification

Le client s'authentifie auprès de l'agent selon l'un de deux modes.

Mode A — TLS mutuel (par défaut)

Définissez ca, cert et key (les trois requis). Le client vérifie l'agent par rapport à votre CA et présente son certificat ; l'agent vous autorise et vous audite par le CN du certificat. C'est le mode par défaut et la posture recommandée.

Mode B — agent auto-signé + secret partagé

Plus simple à exploiter (un secret, pas de PKI) — c'est ce que met en place init. Définissez agent_secret (ou agent_secret_file), et soit un ca pour vérifier l'agent soit insecure: true pour ignorer la vérification. Un certificat client est facultatif (mais cert et key doivent être définis ensemble ou tous deux vides). Votre identité d'audit est la valeur operator (par défaut : votre nom d'utilisateur système).

Passage à v1.17.3 — mettez d'abord les agents à jour

7. Contexte Docker & SSH

--context sélectionne le contexte Docker CLI utilisé pour l'API du manager. Ordre de résolution : --context → $DOCKER_CONTEXT → $DOCKER_HOST → le contexte actif dans ~/.docker/config.json → le socket local unix:///var/run/docker.sock.

Bastion SSH. Si l'hôte du contexte est un point d'accès ssh://, l'API du manager est tunnelisée par SSH — tout comme la connexion à l'agent : comme les points d'accès node:9443 des nœuds ne sont généralement pas routables depuis votre poste de travail, le client tunnelise automatiquement le trafic gRPC de l'agent par le même hôte SSH. Aucune option supplémentaire nécessaire.

8. Options globales

Ces options persistantes s'appliquent à chaque commande :

9. Commandes

init — provisionner les agents

Déploie l'agent comme service Swarm global via l'API du manager : crée un secret Docker de secret partagé, exécute l'agent en mode auto-signé sur chaque nœud (port hôte 9443) et écrit la configuration client correspondante. À exécuter une fois par swarm.

down — retirer les agents

L'inverse de init : retire le service d'agent global et, par défaut, le secret Docker de secret partagé. Il ne touche pas à votre configuration client.

doctor — diagnostiquer le swarm

Vérifie la connexion au manager, si le service d'agent est déployé, et sonde l'agent de chaque nœud prêt pour vérifier sa joignabilité et l'écart de version. Affiche un tableau par nœud (NODE  AGENT  VERSION  PROTO) ; se termine avec un code non nul si le manager est injoignable ou si un agent est en mauvaise santé. Un nœud signalé too old (init --force) exécute un agent plus ancien que votre client — voir redéployer les agents sans changer le secret.

security report — un rapport Markdown sur tout le cluster

La surcouche des risques de sécurité analyse les spécifications des services et affiche le résultat à l'écran. Cette commande écrit la même analyse — plus les contrôles qui relèvent du cluster et d'aucun service en particulier — au format Markdown, pour la relire loin du terminal, la joindre à un ticket, ou la committer à côté de vos fichiers de stack et la comparer d'une version à l'autre. La sortie va sur stdout sauf si -o est donné : elle se redirige aussi facilement qu'elle s'enregistre.

Quatre contrôles s'exécutent au niveau du cluster, et aucun ne peut être répondu par la spécification d'un service :

Ce que le rapport dit de lui-même. Il est lu loin du terminal, par quelqu'un qui n'était pas là quand il a tourné : il porte donc son propre contexte — quel cluster, quand, avec quel build. Il comporte aussi une section Not covered — agents injoignables, configuration du swarm illisible, liste de nœuds vide — parce que le silence dans un rapport de sécurité se lit comme un tout-va-bien sur un terrain qu'il n'a jamais foulé. L'ordre ne dépend que des constats : deux rapports d'un cluster inchangé ne diffèrent que par l'horodatage et peuvent être comparés l'un à l'autre — ce qui ne vaut quelque chose que parce qu'un constat absent signifie non trouvé et jamais non cherché.

Le fichier est écrit en 0600, les répertoires parents créés en 0700. Il nomme chaque service, chaque réseau et chaque secret du cluster avec chaque faiblesse trouvée : c'est une carte des points d'attaque, et elle n'a rien à faire en lecture pour tous les comptes de la machine.

Le même rapport s'écrit depuis la TUI : appuyez sur w dans la surcouche des risques de sécurité. C'est une collecte neuve à l'échelle du cluster, pas un vidage de ce que la surcouche affiche, et elle tourne hors de la goroutine de l'interface — celle-ci reste réactive pendant qu'elle interroge chaque nœud.

stack export / stack diff — une stack déployée sous forme de fichier

stack export relit une stack déployée depuis le cluster et l'écrit en YAML de forme compose. stack diff compare un fichier de stack à ce qui tourne réellement et affiche un diff unifié : une ligne + est ce que déployer le fichier ajouterait, une - ce qu'il retirerait. Comme git diff --exit-code, la commande sort en 1 dès qu'il y a une différence : utilisable en CI.

Dans la TUI, E sur l'onglet Stacks/Services propose les deux pour la stack sous le curseur — la ligne de la stack, un de ses services, ou un de ses conteneurs.

Pourquoi pas une comparaison de texte. Une stack déployée porte ce que le fichier n'a jamais eu : l'empreinte de l'image que le démon a résolue au déploiement, ses propres valeurs par défaut de politique de redémarrage et de mise à jour, et l'espace de noms de la stack préfixé à chaque réseau, secret et volume. Comparer les deux comme du texte signale des dizaines de différences pour une stack pourtant exactement à jour — ce qui est pire que pas d'outil du tout, puisque cela apprend à ignorer la sortie. À la place, le fichier passe par le chargeur et le convertisseur compose de docker eux-mêmes, le code qu'utilise docker stack deploy, puis les deux côtés sont réduits par la même fonction. La question à laquelle il est répondu est « déployer ce fichier changerait-il quelque chose ? », pas « ces deux fichiers sont-ils écrits pareil ? ». Les valeurs par défaut du démon sont retirées des deux côtés ; une valeur qui n'est pas la valeur par défaut s'affiche toujours, donc rien de réel n'est masqué.

Un export est une description, pas une sauvegarde. La valeur d'un secret est en écriture seule dans l'API du moteur — elle ne peut jamais être relue — et le contenu d'un volume vit sur les nœuds. Les deux sont donc déclarés external, et le fichier exporté le dit dans son propre en-tête : recréer la stack ailleurs suppose de créer d'abord les secrets. Les champs de spécification que ce rendu ne porte pas (tty, ulimits, réglages seccomp et AppArmor, et quelques autres) sont nommés au même endroit, car l'échec dangereux d'un outil de comparaison n'est pas une réponse fausse mais un silence assuré : « aucune différence » arrive toujours avec ses réserves.

Les variables sont interpolées depuis votre environnement, exactement comme le fait docker stack deploy. Un fichier contenant ${TAG} décrit donc une stack différente pour un TAG différent, et le diff dépend de l'environnement où il tourne — ce qui est correct : prétendre le contraire signalerait « aucun changement » pour un déploiement qui changerait l'image.

stack deploy — appliquer un fichier de stack, après vérification

Charge un fichier de stack, exécute les contrôles de sécurité sur ce qu'il déploierait réellement, puis l'applique. Ce qui en fait l'intérêt face à docker stack deploy, c'est le garde-fou : le fichier est vérifié avant que quoi que ce soit ne soit créé, et si quelque chose au-dessus de l'informatif est trouvé, le déploiement s'arrête et demande.

Dans la TUI, E → Deploy a file fait de même : d'abord les constats, d poursuit, Esc abandonne. À ce moment rien n'a été créé, ce qui est précisément l'objet de cette pause.

Les contrôles ne sont pas un second jeu de règles. Le fichier est converti exactement en les valeurs ServiceSpec que le déploiement soumettrait, et les huit analyseurs existants tournent dessus — les mêmes contrôles qui posent le bouclier dans l'arbre et remplissent la surcouche ! ainsi que le rapport de sécurité. Deux jeux dériveraient : une règle durcie d'un côté et pas de l'autre signifie que le garde-fou laisse passer un fichier que l'arbre signale dès qu'il tourne — et à qui on a dit « rien trouvé », on a dit quelque chose de faux. Cela fait aussi que les contrôles voient ce que le cluster fera, pas ce que le fichier dit ; les valeurs par défaut et raccourcis de compose sont entre les deux.

--yes ne veut pas dire « ignore les constats ». Cela veut dire « ne demande pas », et une exécution qui trouve quelque chose au-dessus de l'informatif refuse tout de même et sort avec un code non nul. Autrement, le garde-fou deviendrait une formalité dès la première mise en CI. Pour déployer malgré les constats il faut écrire --force : autre chose à taper, autre chose à expliquer ensuite. Une exécution non interactive sans réponse sur stdin compte comme non.

Ce que fait un déploiement, dans cet ordre : réseaux, puis secrets, puis configs, puis services — un service qui référence quelque chose qui n'existe pas encore échoue, et la stack reste à moitié appliquée. Les réseaux externes sont vérifiés en premier, car un réseau inexistant est la façon la plus courante pour un déploiement de s'arrêter à mi-chemin. Un secret existant n'est jamais écrasé : sa valeur est immuable dans swarm, le changer signifie en créer un nouveau sous un autre nom. Si un déploiement échoue malgré tout en cours de route, ce qui a déjà été appliqué est rapporté avec l'erreur plutôt que laissé à deviner.

Redéployer les agents sans changer le secret

Tôt ou tard, vous devrez redéployer les agents sur un swarm déjà provisionné : un agent se bloque, doctor affiche un nœud en too old (init --force), une commande échoue avec « agent is older than this client (missing RPC) — update it with swarmexec init --force », ou un nœud a été réinstallé et son agent n'est jamais revenu. La solution consiste à relancer init avec --force, dont c'est exactement le rôle : mettre à jour le service s'il existe déjà. Sans cette option, lancer init sur un service existant est une erreur d'utilisation qui vous demande d'ajouter --force ; rien n'est modifié.

L'agent est alors redéployé sur chaque nœud et le secret partagé reste inchangé. Les secrets Docker sont immuables : init retrouve le swarmexec_agent_secret existant, le signale comme reusing existing et conserve la valeur déjà présente dans le cluster. Tout client qui fonctionnait avant continue de fonctionner — il n'y a rien à redistribuer.

--save-config vaut true par défaut : un redéploiement réécrit donc aussi ~/.config/swarmexec/config.yaml. Passez --save-config=false dès que la configuration client locale doit rester intacte — par exemple lorsque vous redéployez les agents depuis une machine dont la configuration est déjà correcte, ou depuis la CI.

Vérifiez ensuite. doctor indique un état par nœud ; ok sur tous les nœuds signifie que client, agent et secret sont de nouveau cohérents.

ps — lister les tâches

Liste les tâches/conteneurs candidats et le nœud sur lequel chacun s'exécute. Prend un filtre de service facultatif. Colonnes : SERVICE  SLOT  CONTAINER  NODE  IP  UPTIME. Cela dialogue uniquement avec l'API du manager — cela fonctionne même avant que les agents soient joignables.

exec — exécuter une commande / ouvrir un shell

Exécute dans un conteneur situé n'importe où dans le swarm. Sans commande, il ouvre /bin/sh. Un TTY est alloué automatiquement lorsque stdin est un terminal et que vous n'avez donné aucune commande ; forcez-le avec -t. Le code de sortie propre de la commande distante est propagé tel quel.

logs — diffuser les logs

Diffuse les logs d'un conteneur situé n'importe où dans le swarm.

Analyse & filtrage tenant compte du format. --log-format indique au client comment lire chaque ligne pour qu'il puisse en extraire un niveau et un message : classic extrait un niveau d'une ligne de texte brut, json analyse du JSON de style logstash (champs level/message), logfmt analyse le style clé=valeur utilisé par de nombreuses applications Go, le démon Docker et les outils HashiCorp (msg/message, level/lvl/severity, ts/time), gelf analyse du JSON GELF Graylog (niveau syslog numérique), et raw laisse passer les lignes inchangées. --min-level écarte alors tout ce qui est en dessous du niveau choisi, et --grep ne conserve que les lignes dont le message analysé correspond à la regexp.

Suivi au travers du remplacement de conteneur. Avec -f sur une cible service ou service.slot, logs continue de suivre lorsque le conteneur qu'il diffuse est remplacé par une mise à jour progressive, un redémarrage ou une replanification : il ré-résout le conteneur en cours d'exécution du service (le même emplacement, ou le même nœud pour un service global), se reconnecte automatiquement — comme docker service logs -f — et affiche une ligne d'avis atténuée (container replaced; reconnected to <id> on <node>). Il attend jusqu'à ~30 s qu'un remplaçant soit planifié avant d'abandonner, et s'arrête proprement si le service est retiré. Une cible container-id simple n'a pas de successeur, elle s'arrête donc simplement comme avant.

port-forward (alias pf) — rediriger un port local

Lie un port TCP local et le redirige vers un port à l'intérieur d'un conteneur, sans publier ce port sur le cluster. Le port local prend par défaut la valeur du port distant. Cibler un service redirige vers exactement une de ses tâches (celle vers laquelle la cible se résout), pas à travers les répliques. Lié à 127.0.0.1 par défaut. Appuyez sur Ctrl-C pour arrêter.

volume ls — lister les volumes

Liste les volumes sur tous les nœuds et quels nœuds détiennent chacun. Les volumes Swarm sont locaux au nœud, le client interroge donc chaque nœud et agrège. Filtre de nom par sous-chaîne facultatif. Colonnes : VOLUME  DRIVER  NODES  USED BY  AGE (plus SIZE avec --size).

volume rm — supprimer un volume

Supprime un volume sur chaque nœud qui le détient (--all) ou sur des nœuds précis (--node, répétable). L'un des deux est requis.

ui — TUI interactive

Une vue interactive des conteneurs et des volumes, avec exec, logs et redirection de ports intégrés. Nécessite un terminal interactif. Voir La TUI pour les touches.

config show — inspecter la config

Affiche la configuration client effective et fusionnée avec le secret masqué.

context (alias ctx) — gérer les contextes Docker

Crée et gère les contextes Docker que --context (et $DOCKER_CONTEXT) résolvent pour l'API du manager. swarmexec écrit dans le magasin sur disque propre à docker, donc les contextes créés ici sont interchangeables avec la CLI docker — et vous n'avez plus besoin que docker soit installé, même pour en créer un. Le contexte default intégré ne peut pas être retiré.

context create <name> — crée un contexte pointant sur un hôte manager (prend exactement un argument de nom) :

context ls (alias list) — liste les contextes ; colonnes NAME  CURRENT  DOCKER ENDPOINT (l'actif marqué *) :

context use <name> — définit le contexte courant :

context rm <name> [name...] (alias remove) — retire un ou plusieurs contextes :

Partage des connexions ssh

Avec un contexte ssh://, swarmexec atteint le cluster deux fois par ssh : l'API du manager Docker via l'assistant de connexion d'ssh, et chaque agent de nœud via son propre tunnel vers le même hôte. Chaque exec, chaque flux de logs, chaque redirection de port, chaque relevé de statistiques et chaque cycle de rafraîchissement ouvrait jusqu'ici une connexion ssh neuve — une poignée de main TCP, un échange de clés et une authentification par appel, et autant par hôte de rebond — vers un bastion qui était connecté un instant plus tôt.

swarmexec leur fait désormais partager un seul transport, à l'aide du ControlMaster d'OpenSSH : la première connexion vers une destination l'ouvre, chacune des suivantes devient un canal dessus. Mesuré sur un cluster de trois nœuds derrière un hôte de rebond, swarmexec doctor est passé de 8 authentifications et 3,6 s à 2 et 1,0 s. Le trafic lui-même ne change pas, et le gain croît avec ce que l'on fait dans une session.

• Les sockets de contrôle se trouvent dans $XDG_RUNTIME_DIR/swarmexec/ssh/ (à défaut, le répertoire de cache), créés en 0700 — un socket de contrôle est une session authentifiée bien vivante : il reste dans votre propre arborescence et jamais dans /tmp.
• Un socket par destination et route : deux contextes atteignant le même manager par des hôtes de rebond différents ne partagent rien, car ce n'est pas la même connexion.
• La connexion partagée survit à la commande pendant 60 s, ce qui rend la suivante peu coûteuse, puis se termine d'elle-même. Ensuite, plus rien de swarmexec ne retient de connexion.
• Un socket laissé par un maître tué brutalement est sans danger : ssh constate qu'il est mort et ouvre une connexion ordinaire à la place.
• Indisponible sous Windows, dont OpenSSH n'implémente pas le partage de connexions. Partout ailleurs, SWARMEXEC_SSH_MULTIPLEX=0 le désactive — à savoir si vous configurez vous-même ControlPath, car le réglage de swarmexec passe par la ligne de commande ssh et prime donc sur ~/.ssh/config.

10. La TUI

swarmexec ui possède sept onglets — Stacks/Services (1), Volumes (2), Forwards (3), Networks (4), Secrets (5), Nodes (6), Configs (7) — une barre latérale des contextes sur le bord droit, et un pied de page sur deux lignes : les rappels de touches par onglet en haut, puis une ligne d'état avec le contexte docker actif (ctx <name>, pour qu'il soit toujours clair sur quel cluster vous êtes), un résumé en direct du cluster, le nombre de redirections et — sur l'onglet Volumes — combien de volumes vous avez sélectionnés. Ces touches fonctionnent sur chaque onglet :

La barre d'onglets est adaptative : sur un terminal plus étroit elle bascule sur des libellés courts — St/Sv, Vol, Fwd, Net, Sec, Node, Cfg — pour que les sept onglets restent visibles au lieu que les derniers soient tronqués. (Cfg, c'est Configs.) Les chiffres de raccourci et les zones cliquables à la souris ne changent pas.

Onglet Stacks/Services

L'onglet 1, autrefois intitulé Containers. C'est un seul arbre, stack → service → conteneur, et c'est là que vivent exec, les logs, la redirection de ports, l'inspection et les éditeurs de service.

Vérification de version :latest. Swarm épingle :latest à un digest au moment du déploiement, donc un service étiqueté :latest exécute en réalité une image fixe. swarmexec résout cela auprès du registre (en utilisant vos identifiants docker locaux) et annote la ligne du service juste après l'URI de l'image : la véritable version entre parenthèses — lue depuis le label org.opencontainers.image.version de l'image — et une flèche vers le haut ↑ lorsque le :latest actuel du registre est un digest plus récent que celui sur lequel le service est épinglé (p. ex. nginx:latest (1.4.0) ↑). Au mieux et mis en cache : les erreurs de registre laissent simplement la ligne non annotée. La section IMAGE de la surcouche d'inspection affiche la même version et, lorsqu'une image plus récente existe, une ligne sélectionnable nouvelle version disponible — déplacez-vous dessus et appuyez sur u (ou Enter) pour mettre à jour le service.

Définir une version avec u — pas seulement quand une mise à jour existe. u ne dépend plus qu'une mise à niveau soit proposée. La touche est disponible dans toute inspection de service dont swarmexec a pu lire les tags d'image auprès du registre — aussi bien pour un service épinglé à une version que pour un service sur :latest — et depuis n'importe quelle ligne de la surcouche, si bien que vous n'avez jamais à chercher l'indication. Redéfinir la même version, épingler ce qui tourne actuellement ou revenir à un tag plus ancien sont des usages tout à fait normaux ; inutile d'attendre qu'une mise à jour existe. Le libellé du pied de page vous dit dans quelle situation vous êtes : u update version lorsqu'une version plus récente a été trouvée (la ligne nouvelle version disponible est alors là aussi, avec une cible concrète), et u set version lorsqu'il n'y en a pas.

Ce que u ouvre dépend de ce que connaît le registre. Sur un service épinglé à une version pour lequel une version plus récente existe, c'est le sélecteur de version : un champ dont l'autocomplétion propose les tags plus récents de la même famille, le plus élevé en premier et prérempli avec celui-ci. Sur un service déjà sur le tag le plus récent, c'est le même sélecteur, à ceci près que les suggestions se rabattent sur tous les tags que liste le dépôt (prérempli avec le tag en cours d'exécution) — c'est ainsi que l'on épingle ou que l'on revient en arrière. Un service sur :latest obtient lui aussi le sélecteur, avec tous les tags connus : y choisir une version concrète est la façon de sortir un service :latest du tag flottant pour l'épingler — précisément ce que réclame le constat de risque unpinned-image (voir la surcouche des risques de sécurité plus bas). La seule exception est un service :latest dont une mise à jour de digest est en attente : celui-là reste la simple confirmation sur le nouveau digest du registre qu'il a toujours été, car un sélecteur inviterait à y saisir latest, qui se résout au tag nu et abandonnerait silencieusement l'épinglage par digest que la mise à jour est justement là pour rafraîchir.

Dans le sélecteur, la liste de suggestions est plafonnée à 25 entrées (un dépôt très actif peut en lister des centaines) et le champ reste en texte libre : vous pouvez saisir n'importe quel tag existant, y compris un plus ancien pour l'épingler ou revenir en arrière vers une version éprouvée. Un tag saisi est validé contre les tags du dépôt (un tag qu'il ne liste pas est rejeté), et choisir un tag plus ancien affiche un avertissement de rétrogradation avant de l'appliquer. Dans tous les cas, la modification est un seul ServiceUpdate / mise à jour progressive, derrière une confirmation. Si le registre n'a renvoyé aucun tag et qu'il n'y a pas non plus de cible concrète — registre privé ou injoignable, ou service épinglé par digest — vous obtenez un avis explicatif et rien n'est modifié.

Chaque service est affiché (même un mis à l'échelle à zéro), chaque ligne rendue comme une ligne docker service ls — nom, mode, nombre en cours d'exécution/souhaité, image et ports publiés — et colorée selon son état réel : le nombre en cours d'exécution/souhaité donne la couleur de base (aqua = toutes les tâches actives, orange = partiel, rouge = arrêté, gris = mis à l'échelle à zéro), et un healthcheck en échec la remplace (voir plus bas). Un marqueur ▸/▾ indique si un service est replié ou déplié ; ses conteneurs en cours d'exécution s'imbriquent en dessous. Un service en cours de mise à jour progressive porte un badge coloré sur sa ligne d'arbre — ⟳ updating ou ↺ rolling back — et le même statut apparaît dans l'overlay d'inspection du service ; il disparaît dès que la mise à jour est terminée.

Colorée par le healthcheck, et pas seulement par le nombre de réplicas. La couleur d'une ligne de service venait du seul rapport en cours d'exécution / souhaité : un service dont tous les conteneurs échouaient à leur healthcheck s'affichait donc toujours en un paisible 3/3 aqua. Le compte était juste et la ligne trompeuse. L'état de tâche de Swarm n'aide pas davantage : une tâche est running pendant que son conteneur rate chaque sonde — le verdict doit donc venir du nœud. Une sonde en échec est désormais traitée comme une dégradation de même nature qu'un réplica manquant :

• tous les conteneurs contrôlés unhealthy → la ligne passe au rouge, ce qui est aussi grave qu'aucun en cours d'exécution ;
• certains unhealthy → orange, comme un déploiement à moitié fait ;
• tous healthy → la couleur que le nombre de réplicas donnait déjà à la ligne, inchangée ;
• des conteneurs sans healthcheck déclaré → la ligne n'est pas recolorée du tout. On ne sait rien d'eux, et deviner serait la même erreur dans l'autre sens.

Les marqueurs. Une ligne de service porte ✖ N unhealthy en rouge, ou ◌ N starting en jaune tant que les sondes ne sont pas encore passées ; une feuille de conteneur porte ✖ unhealthy / ◌ starting. Unhealthy prime sur starting : c'est celui sur lequel il faut agir. Une ligne de stack cumule le même marqueur sur tout ce qu'elle contient (voir Regroupé par stack plus bas). Un conteneur sain n'obtient aucun marqueur, ni d'ailleurs un conteneur sans healthcheck — ainsi le marqueur continue de vouloir dire quelque chose. Ils côtoient les marqueurs de ressources cpu/mem ci-dessous, et la santé vient en premier dans la ligne : c'est elle qui contredit le compte juste à côté.

Marqueurs CPU et mémoire en direct. À côté de ces badges, une ligne peut aussi porter ce qu'elle consomme réellement à l'instant : jusqu'ici swarmexec ne pouvait montrer que ce que l'ordonnanceur avait réservé (voir l'onglet Nœuds plus bas). Un conteneur — ou un service — dont l'utilisation dépasse 70 % reçoit un marqueur orange, et 90 % un rouge, en fin de ligne : la ressource nommée en toutes lettres (cpu pour le CPU, mem pour la mémoire) suivie du pourcentage (cpu 94 %, mem 91 %). Si les deux chauffent, les deux apparaissent. Des mots plutôt que des symboles, à largeur égale : un marqueur dont il faut aller chercher le sens ne fait pas son travail, et des lettres ne peuvent pas échouer à s'afficher dans un terminal. En dessous de 70 % rien n'est dessiné, pour que les marqueurs restent un signal et non du papier peint. Une ligne de service prend la pire de ses réplicas, pas la moyenne — une moyenne masque précisément le conteneur qui est sur le point de mourir, celui qu'il faut voir. (La mémoire absolue d'une ligne de service est la somme sur les réplicas ; le pourcentage est le pic.)

De quoi ces pourcentages sont-ils le pourcentage ? Chacun est mesuré par rapport à ce que ce conteneur a réellement le droit d'utiliser : sa propre limite lorsqu'il en a une, la capacité du nœud sinon. C'est là tout l'enjeu — 91 % d'une limite de 256 Mo signifie qu'un OOM kill est proche, 91 % d'un nœud de 64 Go est une tout autre conversation. La vue stats de la surcouche d'inspection affiche les deux côtés de cette division par conteneur et nomme la base sous le tableau.

Regroupé par stack. docker stack deploy étiquette chaque service qu'il crée avec com.docker.stack.namespace. swarmexec lit ce label dans la spec du service que le manager a déjà renvoyée — Swarm n'a aucun objet « stack », ce label est le seul lien — et imbrique l'arbre sur trois niveaux : stack → service → conteneur. Une ligne de stack affiche le nom du stack, combien de services en dépendent et le nombre de tâches en cours d'exécution/souhaité cumulé ((3 svc · 7/8)), coloré selon exactement la même règle qu'une ligne de service : le total en cours d'exécution / souhaité, avec le même remplacement par le healthcheck par-dessus. Les compteurs de synthèse la suivent lorsqu'ils ne sont pas nuls : ⟳ n — les services de ce stack en cours de mise à jour progressive —, 🛡 n — les services présentant un constat de sécurité qui mérite une action, le même bouclier que portent les lignes de service — puis le marqueur de santé, ✖ N unhealthy ou ◌ N starting, cumulé sur tous les conteneurs de tous les services du stack. Même replié, un stack indique donc si quelque chose à l'intérieur demande votre attention. Et c'est ici que la remontée de la santé compte le plus : la ligne de stack est le niveau qu'un opérateur parcourt en premier, un « tout est en ligne » trompeur y est donc pire qu'un étage plus bas, et non moins grave.

Les services créés avec docker service create ne portent pas de label de stack ; ils sont regroupés sous (no stack), qui est toujours trié en dernier et ne repousse donc jamais les vrais stacks vers le bas. Rien n'est masqué : chaque service apparaît toujours exactement une fois. Les stacks sont triés par nom et démarrent dépliés, de sorte que l'arbre groupé montre les mêmes services que l'arbre plat ; les replis que vous faites survivent au rafraîchissement automatique.

Le regroupement est actif par défaut, mais il ne prend effet que lorsqu'au moins un service du cluster porte réellement un label de stack — sur un cluster sans stacks, l'arbre est exactement tel qu'il a toujours été, sans parent (no stack) inutile. s bascule entre l'arbre groupé et la liste plate de services (le pied de page l'indique comme s stacks) ; s'il n'y a aucun label de stack, il le dit plutôt que de redessiner un arbre identique. La touche est réaffectable via stack_group dans keys.yaml.

La recherche (/) ne change pas : le filtre porte toujours sur le service, le conteneur et le nœud. Un stack que le filtre vide disparaît de l'arbre, et les compteurs de chaque ligne de stack décrivent ce qui s'y trouve réellement — ils suivent donc le filtre au lieu d'annoncer des services que vous avez filtrés.

Le menu d'actions propose Logs, Bash, Sh, Shell as user… (demande un utilisateur/UID, comme docker exec -u, pour les images dont l'utilisateur par défaut n'a pas les outils ou les droits nécessaires) et Port forward (les shells indisponibles sont grisés après un sondage). Dans la barre de recherche, Enter conserve le filtre et revient à la liste ; Esc efface le filtre et ferme la barre.

Risques de sécurité (!). À chaque récupération de la liste des services, swarmexec exécute un ensemble de petits analyseurs statiques sur la spec de chaque service — la même spec que le manager a déjà renvoyée : il n'y a donc aucun appel d'API supplémentaire, l'agent n'intervient pas et rien n'est exécuté à l'intérieur de vos conteneurs. Un service porteur d'un constat qui mérite une action est marqué d'un 🛡 en tête de sa ligne dans l'arbre des services, dans un emplacement de largeur fixe devant le nom, de sorte que les boucliers forment une colonne verticale de lecture. Appuyez sur ! pour ouvrir la surcouche des risques de sécurité, et sur w à l'intérieur pour écrire un rapport Markdown sur tout le cluster — qui couvre davantage que la surcouche, puisqu'il ajoute les contrôles relevant du cluster et non d'un service.

Les huit contrôles livrés à ce jour. D'abord ceux qui peuvent marquer un service, puis, en fin de liste, les purement informatifs :

Pourquoi les contrôles informatifs ne marquent jamais un service. Seul un constat au-dessus de low — high ou medium — rend un service actionnable et pose le 🛡 sur sa ligne dans l'arbre. Les constats low (no-resource-limits, unpinned-image et le « no user set » de root-user) sont vrais de presque tous les services d'un cluster réel : les badger mettrait un bouclier sur presque chaque ligne et détruirait précisément le signal en un coup d'œil pour lequel le marqueur existe. Ils ne sont pas pour autant escamotés — dès qu'un service est marqué pour autre chose, ses constats low sont listés avec les autres dans la surcouche, c'est-à-dire là où ils valent vraiment la peine d'être lus.

La surcouche liste chaque service marqué (« N of M service(s) flagged · 8 checks »), groupé par service, chaque constat sur sa propre ligne avec une pastille de sévérité — ● high, ● medium, ● low — un titre court et une explication d'une ligne. Les constats sont triés du plus grave au moins grave. Dès qu'un service est marqué pour quelque chose d'actionnable, ses constats informatifs de niveau low sont listés eux aussi. Si le service sous le curseur en fait partie, il est présélectionné et amené à l'écran. Quand rien n'est marqué, la surcouche le dit explicitement et nomme chaque contrôle qui a tourné (« Checked: Docker socket mounted in, added Linux capabilities, host network, seccomp / AppArmor disabled, container user, secrets in environment variables, missing resource limits, unpinned image. »), de sorte que le feu vert dit aussi ce qu'il couvre ; si la liste des services n'est pas encore chargée, elle indique que rien n'a encore été analysé plutôt que de donner un faux feu vert. j/k font défiler, Esc (ou q, ou ! à nouveau) ferme.

i ouvre une surcouche d'inspection pour le nœud sous le curseur — sur un service elle affiche docker service inspect, et sur une feuille conteneur l'inspection de tâche swarm (la vue du manager de cette instance : état, emplacement, nœud, id du conteneur, spécification du conteneur, ressources et historique d'état). Les deux proviennent du manager du swarm. La surcouche s'ouvre sur un résumé tabulaire, orienté opérateur avec des sections ordonnées par pertinence opérationnelle — réseaux, labels, volumes/montages et secrets (et configs) d'abord, puis ports, image, mode, env, ressources, placement et politique de mise à jour (plus l'état, le nœud et l'id du conteneur pour un conteneur/tâche), avec les ids et horodatages en dernier. La première ligne de la surcouche, à l'intérieur de la bordure et fixée au-dessus du contenu qui défile, est une barre d'onglets qui nomme ses trois vues — table 1   stats 2   raw json 3 — la vue courante dans la couleur d'accentuation ; elle a la même forme que la barre d'onglets de la fenêtre principale : un libellé suivi du chiffre qui le sélectionne. 1, 2 et 3 sautent directement au tableau, aux stats et au JSON brut du démon, et t fait toujours défiler tableau → stats → JSON brut puis revenir. L'indication du pied de page se résume à 1-3/t view, et le titre de la bordure ne répète plus le nom de la vue courante — il dit simplement inspect service foo, puisque la barre indique déjà où vous êtes. Notez que la vue tabulaire est la vue de tâche du manager, pas d'un docker container inspect complet et local au nœud du conteneur en cours d'exécution — une véritable inspection de conteneur via l'agent est prévue.

La vue stats. Celle du milieu montre l'utilisation des ressources en direct — les mêmes relevés que ceux qui marquent l'arbre : l'ouvrir ne coûte aucun appel supplémentaire et les chiffres continuent de se rafraîchir tant qu'elle est ouverte. C'est un tableau, une ligne par conteneur du service (ou l'unique conteneur d'une inspection de tâche) :

Un tableau, parce qu'un pourcentage nu n'est pas lisible si l'on ne sait pas déjà comment l'outil mesure — 94 % de quoi ? Chaque cellule porte ses propres unités : 0.07 / 4.00 cores n'a besoin d'aucune légende, et le pourcentage se tient à côté du chiffre dont il est le pourcentage ; et plusieurs réplicas se comparent en parcourant une colonne plutôt qu'en confrontant des blocs empilés. La colonne HEALTH formule le verdict en toutes lettres : healthy, unhealthy, starting, ou none pour un conteneur qui ne déclare aucun healthcheck. none et healthy sont délibérément deux mots distincts, et non un mot et un vide : « aucun healthcheck configuré » et « la sonde passe » sont deux faits différents, et un vide se lirait comme le second. Un conteneur qu'aucun agent n'a rapporté — nœud injoignable, agent trop ancien pour le RPC Stats, ou conteneur démarré depuis le dernier relevé — affiche no reading dans les deux colonnes de ressources au lieu d'un zéro, qui se lirait comme « au repos ».

La note sous le tableau nomme le dénominateur : la limite propre du conteneur lorsqu'il en a une, la capacité du nœud sinon. C'est cela qui donne un sens à un pourcentage — 85 % d'une limite de 8 Gio et 85 % d'un nœud de 64 Gio sont deux conversations différentes. La mémoire est en unités binaires (MiB/GiB), les mêmes que le détail de nœud et celles que docker rapporte lui-même : le même chiffre ne se lit jamais différemment à deux endroits. Avec plus d'un conteneur mesuré, une synthèse s'ajoute sous le tableau : CPU et mémoire de la pire réplica — pas une moyenne, qui masque justement le conteneur sur le point d'être tué par l'OOM — plus la mémoire totale sur l'ensemble. L'entrée t de la surcouche d'aide ? indique en conséquence cycle table / stats / raw JSON.

La surcouche est navigable et sélectionnable, pas seulement un simple défilement : les lignes de données sont individuellement sélectionnables et vous déplacez le curseur ligne par ligne avec ↑/↓ ou j/k (les en-têtes de section et les lignes vides sont ignorés). y copie toujours la ligne sélectionnée dans votre presse-papiers via OSC52 — le même mécanisme de copie utilisé ailleurs — pour que vous puissiez saisir un seul id, montage ou adresse sans sélectionner de texte à la main. Enter copie aussi, sauf sur une ligne NETWORKS repliable, où il déplie/replie plutôt cette ligne (voir ci-dessous). Les trois vues (le résumé tabulaire, la vue stats et le JSON brut, atteints par 1–3 ou en faisant défiler avec t) sont sélectionnables et copiables ligne par ligne. Un pied de page liste toujours les touches disponibles, de sorte que ce que vous pouvez faire est visible d'un coup d'œil ; pour un service, le pied de page affiche aussi les touches d'édition ci-dessous.

La section NETWORKS est repliable, et elle répond à « à quelle adresse est-ce joint ? » avant même de rien déplier : chaque réseau attaché apparaît comme une ligne repliée + <network> 🔒 vip 10.0.5.2/24 (2 dns names). Une icône de cadenas 🔒 après le nom du réseau signale un réseau overlay chiffré (chiffrement du plan de données, --opt encrypted) ; son absence signifie non chiffré. Sur l'inspection d'un service, l'adresse est étiquetée vip — l'IP virtuelle du service sur ce réseau, l'adresse à laquelle répond le répartiteur de charge du swarm, tirée du ServiceInspect du manager (Endpoint.VirtualIPs). Sur celle d'un conteneur/tâche, elle est étiquetée addr : l'adresse propre de ce conteneur sur ce réseau. Un service en mode d'endpoint dnsrr n'a aucune VIP — c'est voulu, pas une donnée manquante — donc au lieu d'un blanc, le réseau déplié porte la ligne no vip — dnsrr endpoint mode, the DNS name resolves to the containers. Le réseau ingress est lui aussi listé ici, bien qu'aucune spec ne le mentionne — le swarm y attache le service de lui-même (voir plus bas). Il est ajouté après les réseaux que déclare la spec, jamais intercalé entre eux, et son en-tête se lit + ingress vip 10.0.0.250/24 (routing mesh) : la mention (routing mesh) prend la place d'un décompte de noms DNS qui ne pourrait jamais dire que (0 dns names).

Déplacez-vous sur une ligne de réseau et appuyez sur Enter pour la déplier ou la replier. Dépliée, elle liste les noms DNS qui se résolvent vers le service/conteneur sur ce réseau — le nom du service, tasks.<service> et tout alias personnalisé — pour que vous puissiez voir sous quel nom DNS il est joint et quels alias il porte, par réseau. En dessous se trouve une seconde ligne repliable, + 2 containers (au singulier, + 1 container) ; Enter sur celle-ci ouvre le niveau le plus profond : une ligne par conteneur, alignée en colonnes, web.1 10.0.1.5/24 host-a — nom de la tâche, son adresse sur ce réseau, et le nœud sur lequel elle tourne (les tâches répliquées sont nommées <service>.<slot>, les globales <service>.<node>, faute de slot).

Le filtre porte sur l'état souhaité (desired state) de la tâche, pas sur son état courant : toute tâche que le manager veut encore voir tourner est listée, y compris celles qui ne sont que preparing, assigned ou starting — elles détiennent déjà leur adresse, et pendant une mise à jour progressive c'est le cas de la plupart ; filtrer sur l'état courant viderait donc le détail précisément quand il est le plus intéressant. Une tâche que le manager a abandonnée — état souhaité shutdown, c'est-à-dire remplacée par une mise à jour progressive, supprimée par une mise à l'échelle ou en échec — n'est pas listée : son adresse a été libérée et peut déjà appartenir à un autre conteneur, l'afficher serait donc activement faux. Une tâche qui ne sert pas encore de trafic porte son état entre parenthèses en fin de ligne, web.1 10.0.1.5/24 host-a (starting) ; une tâche en cours d'exécution n'a pas de suffixe. Les lignes viennent d'un TaskList de l'API du manager filtré sur le service, au mieux (best-effort) : une erreur d'API laisse simplement le détail vide. Les deux niveaux se replient indépendamment ; replier le réseau masque avec lui le niveau des conteneurs.

La ligne ingress est celle qui ne figure dans aucune spec : le swarm rattache un service au réseau ingress de lui-même dès qu'il publie un port en mode ingress, et cet attachement n'apparaît nulle part dans la spec du service — pourtant sa vip est l'adresse à laquelle le routing mesh répond réellement, ce que l'on veut savoir en premier quand un port publié se comporte mal. Elle obtient donc une ligne à elle, ajoutée après les réseaux déclarés par la spec et de forme légèrement différente : aucun nom DNS de service ne se résout sur ingress, aussi, là où un autre réseau compte ses noms, cet en-tête porte la mention (routing mesh). Dépliée, la ligne liste à la place les ports publiés via ingress qui y ont mené le service — la raison d'être de la ligne —, un par ligne : published 2222 -> 22/tcp. Les ports publiés en mode host contournent le routing mesh et n'y sont délibérément pas listés. En dessous, elle descend jusqu'aux conteneurs exactement comme toute autre ligne de réseau : le même niveau + 1 container, avec l'adresse propre de chaque conteneur sur le réseau ingress. Un service qui ne publie aucun port en ingress n'y a pas de VIP — et donc pas de telle ligne du tout.

Un service GitLab publiant SSH sur 2222, les deux niveaux dépliés :

Copier dans NETWORKS donne l'adresse sans son masque — 10.0.5.2, la forme que vous collez dans un curl ou un ping : sur une ligne de réseau son vip/addr, sur une ligne de conteneur l'adresse de ce conteneur. Une ligne de réseau sans adresse (dnsrr) copie le nom du réseau, comme avant. Sur les deux types de lignes repliables Enter bascule ; sur toute autre ligne il copie (et y copie toujours).

Lorsque vous inspectez un service (pas une feuille conteneur/tâche, dont la surcouche reste en lecture seule), le pied de page de la surcouche expose aussi plusieurs touches d'édition, chacune un ServiceUpdate de l'API du manager qui déclenche une mise à jour progressive / réconciliation des tâches du service.

Commencez par a — le menu d'actions. Sur une inspection de service (et là seulement), a ouvre une liste unique de tous les éditeurs et actions que propose la surcouche, pour ne pas avoir à retenir ~14 touches sensibles à la casse (d/D, s/f, p/l/e, n/S/v, r/P, R, X). C'est le chemin découvrable, sans Maj — et non un chemin réduit : choisir une entrée ferme le menu et ouvre exactement ce qu'ouvre la touche directe ; les deux sont donc équivalents, pas des variantes au comportement différent. Les entrées, dans l'ordre : Update image version… (Set image version… quand il n'y en a pas de plus récente — épingler une version de votre choix ou y revenir est tout aussi valable), Diff spec (previous → current), Roll back to the previous version, Why — placement diagnosis, Scale, Force-update, Edit ports, Edit labels, Edit env, Edit networks, Edit secrets, Edit mounts, Edit resources, Edit placement, Remove service — la destructive, signalée en rouge — et Cancel. On se déplace avec j/k (g/G sautent à la première/dernière entrée), Enter sélectionne ; Esc, ou l'entrée Cancel, ferme le menu sans rien faire. Le sélecteur de version d'image vient en premier, parce que fixer une version est le changement de service le plus ordinaire qui soit ; sa touche directe u fonctionne toujours depuis n'importe quelle ligne de l'inspection. Si l'image est de celles pour lesquelles aucune version ne peut être choisie — une référence sans tag, ou un registre qui refuse de lister les tags du dépôt, typiquement un registre privé sans identifiants —, l'entrée reste dans la liste et le dit au lieu de disparaître en silence, et renvoie vers le docker service update --image qui, lui, fonctionne. La touche directe de chaque entrée :

Ces éditeurs sont étagés : a ajoute une entrée, d supprime celle sous le curseur, y copie l'entrée sélectionnée dans votre presse-papiers via OSC52 (pour que vous puissiez saisir p. ex. une seule variable d'environnement en la consultant), u annule le dernier changement étagé (ajout / édition / suppression) tant que vous n'avez pas encore appliqué — appuyez-y de façon répétée pour remonter dans l'historique étagé — et w applique tous les changements d'un coup en un seul ServiceUpdate (donc ajouter, disons, plusieurs volumes puis appuyer sur w déclenche une mise à jour progressive, pas une par entrée), derrière une confirmation. Si vous appuyez sur Esc alors que des changements sont encore étagés, l'éditeur ne les abandonne pas en silence — il demande s'il faut appliquer, abandonner, ou continuer l'édition. Tant que les changements sont encore étagés, ils sont mis en évidence pour que vous voyiez exactement ce qui va changer : les entrées ajoutées ou éditées apparaissent en vert (nouveau) et les entrées supprimées subsistent comme des lignes atténuées rouge « supprimé » — la mise en évidence s'efface une fois que vous appliquez. Les éditeurs ports, labels, montages, env et alias (alias atteints depuis l'éditeur de réseaux via A) ont aussi e pour éditer l'entrée sous le curseur ; les éditeurs réseaux et secrets n'ont pas de e — une entrée de réseau ou de secret n'est qu'un nom, donc c'est ajout (a) / retrait (d) seulement. Le e de l'éditeur env ouvre une zone de texte multiligne défilable (Ctrl-S enregistrer / Esc annuler) pour les longues valeurs ; les autres éditeurs conservent le champ sur une seule ligne avec Enter pour confirmer.

L'arbre se rafraîchit automatiquement toutes les ~10 s, de sorte qu'un conteneur remplacé ou un service mis à l'échelle en arrière-plan apparaît de lui-même — le curseur et tout service déplié sont préservés. r force toujours un rafraîchissement immédiat.

Onglet Volumes

La suppression tient compte des nœuds : un volume est supprimé sur chaque nœud qui le détient. La purge épargne les volumes qu'un service déclare même si aucune tâche n'est en cours d'exécution, elle n'effacera donc pas les données d'une stack arrêtée. Pour un contrôle plus fin, Enter ouvre la liste par nœud où space sélectionne des nœuds, d supprime la copie du nœud en surbrillance et a supprime sur tous les nœuds — chacun derrière une confirmation.

Onglet Forwards

Un conteneur en cours d'exécution est annoté dans l'arbre par local→remote (p. ex. 9090→8080). Les redirections continuent de fonctionner quand leur surcouche se ferme et quand vous changez de cluster ; elles s'arrêtent sur d ou quand vous quittez l'UI. La colonne CLUSTER nomme le contexte auquel chacune appartient, estompée pour celui que vous regardez — une redirection sur un autre cluster reste la vôtre et continue d'écouter, mais ses colonnes CONTAINER et NODE désignent des choses invisibles d'ici. L'annotation dans l'arbre est par cluster pour la même raison : un identifiant de conteneur n'est unique qu'au sein de son propre démon.

De ce fait, un port local que vous utilisez déjà est refusé d'emblée, en nommant la redirection qui le détient et le cluster auquel elle appartient — le message reste ouvert pour que vous en choisissiez un autre. Le « address already in use » du système reste pour le cas où il a raison : un port détenu par un autre programme, que swarmexec ne peut pas nommer.

Onglet Networks

Une liste des réseaux du swarm — nom, driver, portée, type (ingress / internal / attachable), si le réseau est chiffré et combien de services s'attachent à chacun. La colonne TYPE affiche overlay ou le nom du driver (p. ex. bridge) pour les réseaux ordinaires plutôt qu'un tiret. La colonne ENC affiche 🔒 yes quand le réseau overlay a le chiffrement du plan de données activé (créé avec --opt encrypted), sinon un tiret. Le nom de chaque réseau et sa cellule TYPE sont codés par couleur selon le genre (priorité la plus haute d'abord) :

• attachable — vert
• internal — jaune
• ingress — gris
• autre overlay / à portée swarm — aqua
• local (bridge, host, …) — gris atténué

Attacher ou détacher effectue une mise à jour de service qui ajoute ou retire le réseau dans la spécification du service, puis rafraîchit l'onglet Networks. C'est une opération de l'API du manager (ServiceUpdate) — le même canal que le client utilise pour la topologie — et elle déclenche une mise à jour progressive qui redémarre les tâches du service.

Onglet Secrets

Une liste en lecture seule des secrets du swarm — nom, combien de services utilisent chacun, âge, dernière mise à jour et nombre de labels. Les valeurs des secrets ne sont jamais affichées : l'API Docker ne les expose pas.

Attacher ajoute le secret au service, monté dans /run/secrets/<name> (comme docker service update --secret-add) ; détacher retire la référence de secret. Puis l'onglet Secrets se rafraîchit. Comme l'attachement/détachement réseau, chacun est un ServiceUpdate de l'API du manager qui déclenche une mise à jour progressive redémarrant les tâches du service.

Barre latérale des contextes

Les clusters occupent une colonne sur le bord droit, pas un onglet. Changer de cluster est quelque chose que l'on fait depuis l'endroit où l'on est — et la liste des clusters est précisément ce qui indique où c'est. Elle a donc sa place à l'écran, pas sur une page où il faut se rendre.

c lui donne le clavier depuis n'importe quel onglet ; c à nouveau ou Esc le rend à l'onglet où vous étiez. Le cluster actif est marqué ▶ — le nom que le pied de page affiche. Un cluster déjà visité pendant cette session porte un · vert : il est toujours connecté, donc y basculer est instantané. Un cluster qui a refusé la connexion porte un ✗ rouge. Le contexte default intégré est protégé.

La barre latérale s'ajuste au nom de contexte le plus long et s'efface sur un terminal étroit : en dessous d'environ 92 colonnes elle se masque plutôt que de tronquer l'arbre, et revient tant que c la retient. Les points d'accès ne figurent pas dans la colonne — il n'y a pas la place, et i en montre le détail complet.

Changer de cluster conserve votre session. L'UI ne se reconstruit pas : la position du curseur, les stacks et services dépliés et le filtre / sont mémorisés par cluster, si bien qu'en revenant vous retrouvez exactement l'endroit que vous aviez quitté. Les redirections de port continuent de tourner ; l'onglet Forwards gagne une colonne CLUSTER pour voir d'un coup d'œil lesquelles appartiennent au cluster affiché et lesquelles non.

Seul le cluster que vous regardez est interrogé : en basculant ailleurs, l'autre cesse de se rafraîchir et sa connexion ssh expire d'elle-même peu après. Le premier passage vers un cluster prend le temps qu'il faut pour l'atteindre, car la connexion est établie avant que quoi que ce soit change à l'écran — si elle échoue, on vous dit de quel cluster il s'agit et vous restez sur celui qui fonctionne. Chaque retour ultérieur est immédiat.

Onglet Nodes

Liste les nœuds du swarm avec des informations générales et quelques agrégations — NODE (nom d'hôte ; managers en aqua, le leader marqué ★), ROLE (manager / worker), AVAIL (active / pause / drain, codé par couleur), STATE (ready / down), version ENGINE, TASKS (tâches en cours d'exécution planifiées sur le nœud), VOLS (volumes que le nœud détient — locaux au nœud, donc cela se remplit un instant après le reste) et LABELS (nombre).

Ressources réservées. Les détails du nœud comportent un bloc reserved by tasks (scheduler's view) : pour le CPU et la mémoire, une barre plus réservé / capacité et ce qui reste libre. La barre est verte, passe au jaune à partir de 75 % et au rouge à 100 % ou au-delà ; le surengagement est signalé explicitement, et « libre » ne devient jamais négatif. Un nœud qui n'annonce aucune capacité le dit au lieu de dessiner une barre. Le bloc ne coûte aucun appel d'API supplémentaire — la liste des nœuds récupère déjà la liste des tâches.

Utilisé par les conteneurs. En dessous vient un second bloc — in use by containers (measured on the node) — dessiné avec les mêmes barres proportionnelles : ce que les conteneurs du nœud consomment réellement à cet instant, le CPU en cœurs et la mémoire, chacun face à la capacité du nœud. Les deux blocs sont délibérément séparés, car ils répondent à des questions différentes et sont régulièrement très éloignés l'un de l'autre : un nœud peut être entièrement réservé et inactif, ou à peine réservé et en feu. Les chiffres viennent de l'agent de ce nœud, la même source que les marqueurs d'utilisation de l'arbre des services — tant que le delta CPU n'est pas prêt, la ligne affiche measuring…, et un nœud dont l'agent est injoignable ou trop ancien n'obtient aucun bloc plutôt qu'une rangée de zéros qui se lirait comme « inactif ».

Images sur ce nœud. En dernier, les détails portent un bloc images on this node : ce que pèse le magasin de couches du nœud et en combien d'images, puis ce qui en est récupérable en restes non étiquetés (un nœud qui n'a rien de non étiqueté le dit, plutôt que de proposer un zéro). Lorsqu'il y en a, une ligne supplémentaire indique combien d'espace est en outre étiqueté mais inutilisé — formulé comme un coût, l'enlever oblige à retélécharger ces images, et non comme une offre. Ce bloc existe parce que les images sont la seule ressource locale au nœud que le côté cluster ne voit pas du tout : l'API du manager n'a aucune vue sur les images, contrairement aux volumes, dont elle sait au moins qu'ils sont montés. Les volumes se géraient déjà depuis swarmexec à l'échelle du cluster ; un nœud dont le disque se remplissait silencieusement de vieilles couches n'était même pas visible. Le bloc se charge de son côté, en parallèle de la liste des nœuds, et apparaît donc un instant après le reste de la surcouche.

Récupérer l'espace — P sur l'onglet Nodes. Le menu ouvert comporte deux entrées, délibérément pas une action avec une case à cocher, car ce sont deux actes différents et une case invite à tomber par accident sur le destructeur :

Deux modes, deux autorisations. L'agent les autorise comme deux actions distinctes — image.prune pour les restes non étiquetés et image.prune.all pour le balayage — de sorte qu'une politique peut autoriser la récupération des couches non étiquetées sans autoriser la destructrice. Chaque prune est inscrit dans le journal d'audit de l'agent avec le mode utilisé, l'espace récupéré et le nombre d'images parties.

Même prérequis que les chiffres d'utilisation et de santé ci-dessus : il faut des agents de cette version ou plus récents. Un nœud dont l'agent est plus ancien n'affiche tout simplement aucun bloc images, et signale qu'il n'a pas répondu si vous appuyez sur P — déployez-les avec swarmexec init --force.

Onglet Configs

Onglet 8 — le jumeau de l'onglet Secrets pour l'autre objet que le swarm distribue aux conteneurs, avec une différence décisive : le contenu d'un config est lisible. L'onglet Secrets ne peut jamais montrer une valeur (l'API Docker ne la renvoie pas) ; le détail d'un config affiche le contenu réel, si bien que vous voyez ce qu'un service reçoit vraiment sans passer par docker config inspect. C'est tout l'intérêt de cet onglet.

La liste est en lecture seule : CONFIG (nom), USED BY (combien de services le montent), SIZE, AGE, UPDATED et LABELS (nombre).

Le contenu est récupéré à la demande, à l'ouverture du détail — pas avec la liste — car un config peut être un nginx.conf entier ; en attendant, la vue affiche loading…, et un config vide indique (empty). Ce qui est rendu est un aperçu, plafonné à la fois à 64 Kio et à 500 lignes. Les deux plafonds sont nécessaires : ne borner que les octets laisse encore un fichier fait de lignes très courtes devenir des dizaines de milliers de lignes rendues — chacune indentée —, et c'est précisément ce qui fait ramer la vue. Une troncature est toujours annoncée (« … truncated at 500 lines », ou à la limite d'octets), jamais une coupe silencieuse, et le contenu binaire est signalé, pas déversé (« (binary content, N — not shown) », détecté en cherchant des octets NUL en tête des données). Le config complet est à un docker config inspect de là.

USED BY est dérivé exactement comme dans l'onglet Secrets : le swarm ne tient aucun index inverse d'un config vers ses consommateurs, donc swarmexec lit les spécifications des services (un ServiceList) et reconnaît une référence par l'ID ou le nom du config — une spec peut porter l'une ou l'autre forme, les deux sont donc consultées et fusionnées. Au mieux : si la liste des services ne peut pas être lue, les configs s'affichent quand même, simplement sans cette correspondance.

Shell & logs intégrés

Dans un shell intégré, Ctrl-] détache (sans terminer le processus). La vue des logs — un seul conteneur ou les logs agrégés d'un service — prend en charge la même analyse et le même filtrage tenant compte du format que la commande logs :

La vue rerend les lignes mises en tampon en direct quand vous changez de format, de niveau ou de grep, et la barre de titre affiche l'état actif fmt:… lvl:… grep:….

Lors du suivi, la vue des logs se reconnecte au travers du remplacement de conteneur de la même façon que la commande logs — à la fois pour les logs d'un seul conteneur et les logs agrégés d'un service (chaque réplique suivie par emplacement). Les avis de reconnexion apparaissent en ligne dans la vue des logs.

Visualiseur de logs

Appuyez sur ` (accent grave) depuis n'importe quel onglet pour basculer une surcouche de logs en direct. Elle affiche les enregistrements les plus récents du tampon circulaire en mémoire — les plus récents en bas — se rafraîchissant tant qu'elle est ouverte et codée par couleur selon le niveau (rouge = error, jaune = warn, gris = debug). ↑/↓ défilent ; Esc, q ou ` la ferment. C'est la fenêtre de la TUI sur les mêmes logs qui vont dans le fichier de log, puisque le terminal lui-même ne peut pas les afficher pendant que l'UI dessine.

Touches personnalisées

Les touches de raccourci sont remappables dans ~/.config/swarmexec/keys.yaml (à côté de config.yaml ; remplacez le chemin avec $SWARMEXEC_KEYS). Chaque valeur est une seule touche, ou le mot space. Les touches structurelles — Enter, Esc, Tab, les flèches, les touches de numéro d'onglet 1–8 et les alias vim j/k/g/G — sont fixes. Le pied de page affiche toujours vos touches réelles, et la surcouche ? les liste toutes.

Le chargement n'échoue jamais : une touche invalide ou réservée, une action inconnue, ou deux actions liées à la même touche sur un onglet se rabattent chacune sur le défaut, et l'UI affiche les avertissements une fois au démarrage.

11. Codes de sortie