← swarm-exec.cloud-surfers.net

swarmexec_ Doku

Den Client bedienen — Befehle, Flags, Konfiguration & die TUI.

swarmexec bietet dir docker exec -it, Logs, Port-Forwarding und Volume-Verwaltung für jeden Container in einem Docker Swarm, aus einem einzigen Terminal. Ein kleiner Agent pro Node (ein globaler Swarm-Service) erledigt die Arbeit auf seinem Node; der Client fragt den Swarm-Manager, welcher Node dein Ziel ausführt, und verbindet sich dann direkt mit dem Agent dieses Nodes über mTLS. Diese Seite dokumentiert den Client.

1. Wie es funktioniert

Zwei Binaries, ein Wire-Protokoll:

• agent — läuft als global Swarm-Service (eine Task pro Node), bindet den Docker-Socket des Nodes ein und stellt eine schmale gRPC-API bereit, die exec / logs / port-forward in Container auf seinem eigenen Node weiterreicht. Du rollst ihn einmal mit swarmexec init aus.
• client (diese CLI) — läuft auf deiner Workstation. Er spricht mit der Swarm-Manager-API, um aufzulösen, welcher Node dein Ziel ausführt und wie die Container-ID lautet, und verbindet sich dann direkt mit dem Agent dieses Nodes auf Port 9443. Es gibt kein Agent-zu-Agent-Mesh.

Die Manager-Verbindung nutzt deinen Docker-CLI-Context (sie berücksichtigt also --context, ssh://-Bastions, mTLS usw.). Die Agent-Verbindung wird mit mutual TLS authentifiziert, oder mit einem geteilten Secret gegen einen selbstsignierten Agent — siehe Authentifizierung.

2. Installation

Setzt Docker Engine 19.03 oder neuer voraus (API 1.40) — auf dem Manager und auf jedem Node. swarmexec lehnt einen älteren Daemon schon beim Verbinden ab und nennt dabei beide Versionen, statt sich zu verbinden und dann eine Ansicht nach der anderen scheitern zu lassen. Zwei Funktionen brauchen vom Daemon des Nodes etwas mehr: die Live-Auslastung und die Image-Ansicht pro Node wollen Docker 23.0 (API 1.41/1.42) — darunter bleiben sie leer und sagen das auch, statt zu scheitern.

Der Client ist ein einzelnes statisches Binary. Hol dir den aktuellen Release-Build für deine Plattform:

Builds: linux-amd64, linux-arm64, darwin-arm64, darwin-amd64, windows-amd64. Das Agent-Image ist öffentlich auf Docker Hub als logleio/swarmexec-agent verfügbar.

3. Schnellstart

Richte deinen Docker-Context auf einen Swarm-Manager aus und provisioniere die Agents dann einmalig. init erzeugt ein geteiltes Secret, rollt den Agent auf jedem Node im selbstsignierten Modus aus und schreibt eine passende Client-Konfiguration — damit die übrigen Befehle sofort funktionieren.

Baue die Agents wieder mit swarmexec down ab (deine Client-Konfiguration bleibt dabei unangetastet).

4. Ziel-Selektoren

exec, logs und port-forward nehmen ein Ziel als erstes Argument. Es wird in dieser Reihenfolge aufgelöst:

Mehrdeutigkeit. Ein bloßer Service-Name mit mehreren Replicas lässt sich nicht auf eine einzelne Task auflösen. exec fordert dich interaktiv auf, aus einer nummerierten Liste zu wählen; logs und port-forward fragen nie nach — sie geben die Kandidatenliste aus und beenden sich. Vereindeutige mit einem Slot (web.0, web.1, …).

5. Konfiguration

Einstellungen kommen aus vier Ebenen, jede überschreibt die vorherige:

Ein Flag überschreibt nur, wenn du es tatsächlich angibst, sodass ein Wert aus der Datei oder der Umgebung erhalten bleibt, solange er nicht ausdrücklich überschrieben wird.

Konfigurationsdatei

Der Standardpfad ist der erste der folgenden, der gesetzt ist:

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

Überschreibe ihn mit --config <path>. Die Datei ist YAML; eine fehlende Datei ist in Ordnung, eine fehlerhafte ist ein Fehler. Sie wird mit 0600 geschrieben (sie kann das geteilte Secret enthalten). Die Log-Datei liegt standardmäßig daneben — ~/.config/swarmexec/swarmexec.log — sofern du nicht --log-file setzt. Schlüssel:

Der logs:-Abschnitt legt Standardwerte für formatbewusstes Log-Parsing und -Filtern fest; die Flags --log-format / --min-level des logs-Befehls überschreiben sie:

Inspiziere die effektive, zusammengeführte Konfiguration (Secret maskiert) mit:

addr-mode

hostname (Standard) wählt den gemeldeten Hostnamen des Nodes an; ip wählt seine angekündigte Adresse an. Verwende ip, wenn die Node-Hostnamen von deiner Workstation aus nicht auflösbar sind — init schreibt genau deshalb addr_mode: ip in die generierte Konfiguration. Der Swarm-Leader meldet 0.0.0.0 für sich selbst; der Client stellt seine echte Adresse automatisch aus der Raft-Peer-Liste wieder her.

Umgebungsvariablen

6. Authentifizierung

Der Client authentifiziert sich gegenüber dem Agent in einem von zwei Modi.

Modus A — mutual TLS (Standard)

Setze ca, cert und key (alle drei erforderlich). Der Client verifiziert den Agent gegen deine CA und präsentiert sein Zertifikat; der Agent autorisiert und auditiert dich anhand des CN des Zertifikats. Das ist der Standard und die empfohlene Vorgehensweise.

Modus B — selbstsignierter Agent + geteiltes Secret

Einfacher zu betreiben (ein Secret, keine PKI) — das richtet init ein. Setze agent_secret (oder agent_secret_file) und entweder eine ca, um den Agent zu verifizieren, oder insecure: true, um die Verifizierung zu überspringen. Ein Client-Zertifikat ist optional (aber cert und key müssen gemeinsam gesetzt oder beide leer sein). Deine Audit-Identität ist der Wert von operator (Standard: dein OS-Benutzername).

Umstieg auf v1.17.3 — zuerst die Agents aktualisieren

7. Docker-Context & SSH

--context wählt den Docker-CLI-Context, der für die Manager-API verwendet wird. Auflösungsreihenfolge: --context → $DOCKER_CONTEXT → $DOCKER_HOST → der aktive Context in ~/.docker/config.json → der lokale Socket unix:///var/run/docker.sock.

SSH-Bastion. Wenn der Context-Host ein ssh://-Endpoint ist, wird die Manager-API über SSH getunnelt — und die Agent-Verbindung ebenfalls: Da die node:9443-Endpoints der Nodes von deiner Workstation aus meist nicht routbar sind, tunnelt der Client den gRPC-Verkehr des Agents automatisch über denselben SSH-Host. Keine zusätzlichen Flags nötig.

8. Globale Flags

Diese persistenten Flags gelten für jeden Befehl:

9. Befehle

init — die Agents provisionieren

Rollt den Agent als globalen Swarm-Service über die Manager-API aus: erstellt ein Docker-Secret mit geteiltem Secret, führt den Agent im selbstsignierten Modus auf jedem Node aus (Host-Port 9443) und schreibt die passende Client-Konfiguration. Führe es einmal pro Swarm aus.

down — die Agents entfernen

Das Gegenstück zu init: entfernt den globalen Agent-Service und standardmäßig das Docker-Secret mit dem geteilten Secret. Es rührt deine Client-Konfiguration nicht an.

doctor — den Swarm diagnostizieren

Prüft die Manager-Verbindung, ob der Agent-Service ausgerollt ist, und testet den Agent jedes bereiten Nodes auf Erreichbarkeit und Versionsabweichung. Gibt eine Tabelle pro Node aus (NODE  AGENT  VERSION  PROTO); beendet sich mit einem Wert ungleich null, wenn der Manager nicht erreichbar ist oder ein Agent unhealthy ist. Ein Node mit dem Status too old (init --force) betreibt einen Agent, der älter ist als dein Client — siehe Agents neu ausrollen, ohne das Secret zu ändern.

security report — ein Markdown-Bericht über den ganzen Cluster

Das Sicherheitsrisiken-Overlay prüft Service-Specs und zeigt das Ergebnis auf dem Bildschirm. Dieser Befehl schreibt dieselbe Prüfung — plus die Checks, die dem Cluster gehören und keinem einzelnen Service — als Markdown heraus. So lässt sie sich fern vom Terminal lesen, an ein Ticket hängen oder neben die Stack-Dateien committen und von Release zu Release diffen. Die Ausgabe geht nach stdout, solange kein -o angegeben ist, ist also genauso gut pipebar wie speicherbar.

Vier Prüfungen laufen auf Cluster-Ebene, von denen keine ein Service-Spec beantworten kann:

Was der Bericht über sich selbst sagt. Er wird fern vom Terminal gelesen, von jemandem, der beim Lauf nicht dabei war — also trägt er seinen Kontext mit: welcher Cluster, wann, mit welchem Build. Außerdem hat er einen Abschnitt Not covered — nicht erreichte Agenten, unlesbare Swarm-Konfiguration, leere Node-Liste —, denn Schweigen in einem Sicherheitsbericht liest sich als Entwarnung für Boden, den er nie betreten hat. Die Reihenfolge hängt allein von den Befunden ab, zwei Berichte eines unveränderten Clusters unterscheiden sich also nur im Zeitstempel und lassen sich gegeneinander diffen — was nur deshalb etwas wert ist, weil ein fehlender Befund nicht gefunden heißt und nie nicht geschaut.

Die Datei wird 0600 geschrieben, eventuell nötige Elternverzeichnisse 0700. Sie nennt jeden Service, jedes Netz und jedes Secret des Clusters samt jeder gefundenen Schwäche — das ist eine Angriffskarte, und die hat nichts in einer für jedes Konto der Maschine lesbaren Datei verloren.

Denselben Bericht schreibt auch das TUI: w im Sicherheitsrisiken-Overlay. Er wird dabei frisch clusterweit erhoben, ist also kein Abzug dessen, was das Overlay zeigt, und läuft außerhalb der UI-Goroutine — die Oberfläche bleibt bedienbar, während er jeden Node abfragt.

stack export / stack diff — ein deployter Stack als Datei

stack export liest einen deployten Stack aus dem Cluster zurück und schreibt ihn als Compose-förmiges YAML. stack diff vergleicht eine Stack-Datei mit dem, was tatsächlich läuft, und gibt einen Unified Diff aus: eine +-Zeile ist etwas, das ein Deploy der Datei hinzufügen würde, eine --Zeile etwas, das es entfernen würde. Wie git diff --exit-code endet der Befehl mit 1, sobald es Unterschiede gibt — also auch in CI brauchbar.

Im TUI bietet E auf dem Stacks/Services-Tab beides für den Stack unter dem Cursor an — die Stack-Zeile, ein Service darin oder einer seiner Container.

Warum kein Textvergleich. Ein deployter Stack trägt Dinge, die die Datei nie hatte: den Image-Digest, den der Daemon beim Deploy aufgelöst hat, seine eigenen Defaults für Restart- und Update-Policy, und den Stack-Namespace vor jedem Netz, Secret und Volume. Beide als Text zu vergleichen meldet Dutzende Unterschiede für einen Stack, der exakt synchron ist — und das ist schlimmer als gar kein Werkzeug, weil man lernt, die Ausgabe zu ignorieren. Stattdessen läuft die Datei durch Dockers eigenen Compose-Loader und -Converter, denselben Code, den docker stack deploy nutzt, und beide Seiten werden anschließend von derselben Funktion reduziert. Beantwortet wird die Frage „würde ein Deploy dieser Datei etwas ändern?“, nicht „sind diese beiden Dateien gleich geschrieben?“. Daemon-Defaults fallen auf beiden Seiten weg; ein Wert, der nicht der Default ist, erscheint weiterhin — es wird also nichts Echtes verborgen.

Ein Export ist eine Beschreibung, kein Backup. Der Wert eines Secrets ist in der Engine-API nur schreibbar und nie wieder auslesbar, und Volume-Inhalte liegen auf den Nodes. Beides wird deshalb als external deklariert, und die exportierte Datei sagt das in ihrem eigenen Kopf: den Stack anderswo neu aufzubauen heißt, zuerst die Secrets anzulegen. Spec-Felder, die das Rendering nicht trägt (tty, ulimits, seccomp- und AppArmor-Einstellungen und einige weitere), stehen an derselben Stelle — denn der gefährliche Fehler eines Vergleichswerkzeugs ist nicht die falsche Antwort, sondern das selbstsichere Schweigen. „Keine Unterschiede“ kommt daher immer mit seinen Vorbehalten.

Variablen werden aus deiner Umgebung interpoliert, genau wie bei docker stack deploy. Eine Datei mit ${TAG} beschreibt also für ein anderes TAG einen anderen Stack, und der Diff hängt von der Umgebung ab, in der er läuft — was richtig ist: alles andere würde „keine Änderung“ melden für ein Deploy, das das Image austauscht.

stack deploy — eine Stack-Datei einspielen, nach Prüfung

Lädt eine Stack-Datei, lässt die Sicherheitsprüfungen über das laufen, was tatsächlich ausgerollt würde, und spielt sie ein. Was das gegenüber docker stack deploy wertvoll macht, ist der Gate: die Datei wird geprüft, bevor irgendetwas angelegt ist, und wenn etwas oberhalb von „informativ“ gefunden wird, hält der Deploy an und fragt.

Im TUI macht E → Deploy a file dasselbe: zuerst die Befunde, d fährt fort, Esc geht weg. Zu diesem Zeitpunkt ist nichts angelegt — genau dafür ist die Pause da.

Die Prüfungen sind kein zweiter Regelsatz. Die Datei wird in genau die ServiceSpec-Werte umgewandelt, die der Deploy einreichen würde, und darauf laufen die vorhandenen acht Analyzer — dieselben Prüfungen, die im Baum den Schild setzen und das !-Overlay sowie den Security-Report füllen. Zwei Sätze würden auseinanderdriften: eine Regel, die an einer Stelle verschärft wird und an der anderen nicht, heißt, dass der Gate eine Datei durchlässt, die der Baum im selben Moment markiert, in dem sie läuft — und wem „nichts gefunden“ gesagt wurde, dem wurde etwas Falsches gesagt. Außerdem sehen die Prüfungen so, was der Cluster tun wird, nicht was die Datei sagt; Composes Defaults und Kurzschreibweisen liegen dazwischen.

--yes heißt nicht „ignoriere die Befunde“. Es heißt „frag nicht“, und ein Lauf, der etwas oberhalb von „informativ“ findet, verweigert trotzdem und endet mit Exit ungleich null. Alles andere würde den Gate zur Formalie machen, sobald ihn jemand in CI einbaut. Um trotz Befunden auszurollen, muss man --force schreiben — anderer Tastendruck, andere Rechtfertigung hinterher. Ein nicht-interaktiver Lauf ohne Antwort auf stdin zählt als Nein.

Was ein Deploy tut, in dieser Reihenfolge: Netze, dann Secrets, dann Configs, dann Services — ein Service, der auf etwas noch nicht Vorhandenes verweist, scheitert, und der Stack bleibt halb angewandt zurück. Externe Netze werden zuerst geprüft, denn ein nicht existierendes ist der häufigste Grund, warum ein Deploy auf halber Strecke stehen bleibt. Ein vorhandenes Secret wird nie überschrieben: sein Wert ist in Swarm unveränderlich, ein Secret zu ändern heißt, ein neues unter neuem Namen anzulegen. Scheitert ein Deploy doch mittendrin, wird das bereits Angewandte zusammen mit dem Fehler gemeldet, statt es erraten zu lassen.

Agents neu ausrollen, ohne das Secret zu ändern

Früher oder später musst du die Agents in einem bereits provisionierten Swarm neu ausrollen: ein Agent hängt, doctor zeigt einen Node als too old (init --force), ein Kommando scheitert mit „agent is older than this client (missing RPC) — update it with swarmexec init --force“, oder ein Node wurde neu aufgesetzt und sein Agent kam nie zurück. Die Lösung ist, init mit --force erneut auszuführen — das Flag bedeutet genau den Service aktualisieren, falls er bereits existiert. Ohne das Flag ist ein init auf einen bestehenden Service ein Usage-Fehler, der dich auffordert, --force zu ergänzen; geändert wird dabei nichts.

Damit wird der Agent auf jedem Node neu ausgerollt, und das geteilte Secret bleibt unangetastet. Docker-Secrets sind unveränderlich, also findet init das vorhandene swarmexec_agent_secret, meldet es als reusing existing und behält den Wert, der bereits im Cluster liegt. Jeder Client, der vorher funktioniert hat, funktioniert danach weiter — es muss nichts neu verteilt werden.

--save-config steht standardmäßig auf true, ein erneutes Ausrollen schreibt also auch ~/.config/swarmexec/config.yaml neu. Übergib --save-config=false, wenn die lokale Client-Konfiguration unberührt bleiben muss — etwa wenn du die Agents von einem Rechner aus neu ausrollst, dessen Konfiguration bereits korrekt ist, oder aus der CI.

Danach prüfen: doctor meldet einen Status pro Node; ok auf jedem Node heißt, dass Client, Agent und Secret wieder zusammenpassen.

ps — Tasks auflisten

Listet mögliche Tasks/Container und den Node, auf dem jede läuft. Nimmt einen optionalen Service-Filter. Spalten: SERVICE  SLOT  CONTAINER  NODE  IP  UPTIME. Dies spricht nur mit der Manager-API — es funktioniert sogar, bevor die Agents erreichbar sind.

exec — einen Befehl ausführen / eine Shell öffnen

Exec in einen Container, der irgendwo im Swarm läuft. Ohne Befehl öffnet es /bin/sh. Ein TTY wird automatisch zugewiesen, wenn stdin ein Terminal ist und du keinen Befehl angegeben hast; erzwinge es mit -t. Der eigene Exit-Code des Remote-Befehls wird unverändert weitergegeben.

logs — Logs streamen

Streame die Logs eines Containers von irgendwo im Swarm.

Formatbewusstes Parsen & Filtern. --log-format sagt dem Client, wie er jede Zeile lesen soll, damit er eine Stufe und eine Nachricht herausziehen kann: classic extrahiert eine Stufe aus einer reinen Textzeile, json parst JSON im Logstash-Stil (level/message-Felder), logfmt parst den key=value-Stil, den viele Go-Anwendungen, der Docker-Daemon und HashiCorp-Tools verwenden (msg/message, level/lvl/severity, ts/time), gelf parst Graylog-GELF-JSON (numerische Syslog-Stufe) und raw reicht Zeilen unverändert durch. --min-level verwirft dann alles unterhalb der gewählten Stufe, und --grep behält nur Zeilen, deren geparste Nachricht dem Regexp entspricht.

Folgen über Container-Ersetzung hinweg. Mit -f auf einem service- oder service.slot-Ziel folgt logs weiter, wenn der gestreamte Container durch ein Rolling Update, einen Neustart oder eine Neuplanung ersetzt wird: es löst den aktuell laufenden Container des Service neu auf (denselben Slot, oder denselben Node bei einem global-Service), verbindet sich automatisch neu — wie docker service logs -f — und gibt eine gedimmte Hinweiszeile aus (container replaced; reconnected to <id> on <node>). Es wartet bis zu ~30s, bis ein Ersatz eingeplant wird, bevor es aufgibt, und stoppt sauber, wenn der Service entfernt wird. Ein bloßes container-id-Ziel hat keinen Nachfolger und stoppt daher einfach wie zuvor.

port-forward (Alias pf) — einen lokalen Port weiterleiten

Bindet einen lokalen TCP-Port und leitet ihn an einen Port innerhalb eines Containers weiter, ohne diesen Port im Cluster zu veröffentlichen. Der lokale Port entspricht standardmäßig dem entfernten. Ein Service als Ziel leitet an genau eine seiner Tasks weiter (die, auf die das Ziel aufgelöst wird), nicht über Replicas hinweg. Standardmäßig an 127.0.0.1 gebunden. Drücke Ctrl-C zum Stoppen.

volume ls — Volumes auflisten

Listet Volumes über alle Nodes hinweg und welche Nodes jedes halten. Swarm-Volumes sind node-lokal, der Client fragt daher jeden Node ab und aggregiert. Optionaler Teilstring-Namensfilter. Spalten: VOLUME  DRIVER  NODES  USED BY  AGE (plus SIZE mit --size).

volume rm — ein Volume entfernen

Entfernt ein Volume auf jedem Node, der es hält (--all), oder auf bestimmten Nodes (--node, wiederholbar). Eines von beiden ist erforderlich.

ui — interaktive TUI

Eine interaktive Ansicht von Containern und Volumes, mit integriertem exec, logs und Port-Forwarding. Braucht ein interaktives Terminal. Siehe Die TUI für die Tasten.

config show — Konfiguration inspizieren

Gibt die effektive, zusammengeführte Client-Konfiguration mit maskiertem Secret aus.

context (Alias ctx) — Docker-Contexts verwalten

Erstellt und verwaltet die Docker-Contexts, die --context (und $DOCKER_CONTEXT) für die Manager-API auflösen. swarmexec schreibt docker's eigenen On-Disk-Speicher, sodass hier erstellte Contexts mit der docker-CLI austauschbar sind — und du brauchst docker nicht mehr installiert, selbst um einen zu erstellen. Der eingebaute default-Context kann nicht entfernt werden.

context create <name> — erstellt einen Context, der auf einen Manager-Host zeigt (nimmt genau ein Namensargument):

context ls (Alias list) — Contexts auflisten; Spalten NAME  CURRENT  DOCKER ENDPOINT (der aktive mit * markiert):

context use <name> — den aktuellen Context setzen:

context rm <name> [name...] (Alias remove) — einen oder mehrere Contexts entfernen:

Gemeinsame ssh-Verbindungen

Bei einem ssh://-Kontext erreicht swarmexec den Cluster gleich zweimal über ssh: die Docker-Manager-API über ssh's Connection-Helper, und jeden Node-Agenten über einen eigenen Tunnel zum selben Host. Jedes Exec, jeder Log-Stream, jedes Port-Forward, jeder Stats-Poll und jeder Refresh-Zyklus öffnete bisher eine frische ssh-Verbindung — ein TCP-Handshake, ein Schlüsselaustausch und eine Authentifizierung pro Dial, und noch einmal pro Jump-Host — gegen einen Bastion-Host, der einen Moment vorher schon verbunden war.

swarmexec lässt sie jetzt einen Transport teilen, mit OpenSSHs eigenem ControlMaster: die erste Verbindung zu einem Ziel öffnet ihn, jede weitere wird ein Kanal darauf. Gemessen an einem Drei-Node-Cluster hinter einem Jump-Host ging swarmexec doctor von 8 Authentifizierungen und 3,6 s auf 2 und 1,0 s. Am Verkehr selbst ändert sich nichts, und der Effekt wächst mit dem, was man in einer Sitzung tut.

• Die Control-Sockets liegen in $XDG_RUNTIME_DIR/swarmexec/ssh/ (ersatzweise im Cache-Verzeichnis), angelegt mit 0700 — ein Control-Socket ist eine lebende, authentifizierte Sitzung, also bleibt er im eigenen Verzeichnisbaum und niemals in /tmp.
• Ein Socket pro Ziel und Route: zwei Kontexte, die denselben Manager über verschiedene Jump-Hosts erreichen, teilen sich nichts — sie sind nicht dieselbe Verbindung.
• Die geteilte Verbindung überlebt das Kommando um 60 s, damit das nächste billig ist, und beendet sich dann von selbst. Danach hält nichts von swarmexec mehr eine Verbindung.
• Ein Socket, den ein hart beendeter Master hinterlassen hat, ist harmlos: ssh stellt fest, dass er tot ist, und öffnet stattdessen eine normale Verbindung.
• Unter Windows nicht verfügbar — dessen OpenSSH kennt keine geteilten Verbindungen. Überall sonst schaltet SWARMEXEC_SSH_MULTIPLEX=0 es ab — relevant, wenn Sie ControlPath selbst konfigurieren, denn swarmexecs Einstellung steht auf der ssh-Kommandozeile und hat damit Vorrang vor ~/.ssh/config.

10. Die TUI

swarmexec ui hat sieben Tabs — Stacks/Services (1), Volumes (2), Forwards (3), Networks (4), Secrets (5), Nodes (6), Configs (7) — eine Context-Sidebar am rechten Rand und einen zweizeiligen Footer: oben die Tastenhinweise pro Tab, dann eine Statuszeile mit dem aktiven Docker-Context (ctx <name>, sodass immer klar ist, auf welchem Cluster du bist), einer Live-Cluster-Zusammenfassung, der Anzahl der Forwards und — im Volumes-Tab — wie viele Volumes du ausgewählt hast. Diese Tasten funktionieren auf jedem Tab:

Die Tab-Leiste ist responsiv: in einem schmaleren Terminal wechselt sie auf Kurzlabels — St/Sv, Vol, Fwd, Net, Sec, Node, Cfg — damit alle sieben Tabs sichtbar bleiben, statt dass die letzten abgeschnitten werden. (Cfg ist Configs.) Die Zifferntasten und die Maus-Klickflächen bleiben unverändert.

Stacks/Services-Tab

Tab 1, früher Containers. Er ist ein Baum, Stack → Service → Container, und darin stecken Exec, Logs, Port-Forwarding, Inspect und die Service-Editoren.

:latest-Versionsprüfung. Swarm fixiert :latest zum Deploy-Zeitpunkt auf einen Digest, sodass ein mit :latest getaggter Service tatsächlich ein festes Image ausführt. swarmexec löst das gegen die Registry auf (mit deinen lokalen Docker-Anmeldedaten) und annotiert die Service-Zeile direkt nach der Image-URI: die echte Version in Klammern — aus dem org.opencontainers.image.version-Label des Images gelesen — und einen Aufwärtspfeil ↑, wenn das aktuelle :latest der Registry ein neuerer Digest ist als der, auf den der Service fixiert ist (z. B. nginx:latest (1.4.0) ↑). Best-Effort und gecacht: Registry-Fehler lassen die Zeile einfach ohne Annotation. Der IMAGE-Abschnitt des Inspect-Overlays zeigt dieselbe Version und, wenn ein neueres Image existiert, eine auswählbare newer version available-Zeile — geh darauf und drücke u (oder Enter), um den Service zu aktualisieren.

Version setzen mit u — nicht nur, wenn es ein Update gibt. u hängt nicht mehr davon ab, dass ein Upgrade angeboten wird. Es steht in jedem Service-Inspect zur Verfügung, dessen Image-Tags swarmexec aus der Registry lesen konnte — bei versionsgepinnten und bei :latest-Services gleichermaßen — und aus jeder Zeile des Overlays, sodass du den Hinweis nie suchen musst. Dieselbe Version erneut setzen, das aktuell Laufende pinnen oder auf einen älteren Tag zurückgehen sind ganz normale Anwendungsfälle; du musst nicht warten, bis es ein Update gibt. Der Text in der Fußzeile zeigt dir, in welcher Situation du bist: u update version, wenn eine neuere Version gefunden wurde (dann gibt es auch die newer version available-Zeile mit einem konkreten Ziel), und u set version, wenn nicht.

Was u öffnet, hängt davon ab, was die Registry weiß. Bei einem versionsgepinnten Service mit einer neueren Version ist es die Versionsauswahl: ein Eingabefeld, dessen Autovervollständigung die neueren Tags derselben Familie vorschlägt, höchste zuerst und mit der höchsten vorbelegt. Läuft der Service bereits auf dem neuesten Tag, ist es dieselbe Auswahl, nur fallen die Vorschläge auf alle Tags des Repos zurück (vorbelegt mit dem laufenden Tag) — so pinnst du oder rollst zurück. Ein Service auf :latest bekommt die Auswahl ebenfalls, mit allen bekannten Tags: eine konkrete Version dort zu wählen ist der Weg, einen :latest-Service vom gleitenden Tag weg zu pinnen — genau das, was der Risiko-Befund unpinned-image (siehe das Sicherheits-Overlay weiter unten) verlangt. Die einzige Ausnahme ist ein :latest-Service mit anstehendem Digest-Update: Der bleibt bei der einzelnen Bestätigung auf den neuen Digest der Registry, die er immer war — eine Auswahl würde dort dazu verleiten, latest einzutippen, was auf das nackte Tag auflöst und damit still genau die Digest-Pinnung wegwerfen würde, die das Update auffrischen soll.

In der Auswahl ist die Vorschlagsliste auf 25 Einträge begrenzt (ein viel genutztes Repo listet leicht Hunderte), und das Feld bleibt frei editierbar: du kannst jeden vorhandenen Tag eintippen, auch einen älteren, um ihn zu pinnen oder zurückzurollen auf ein bewährtes Release. Ein eingetippter Tag wird gegen die Repo-Tags geprüft (ein nicht gelisteter Tag wird abgelehnt), und die Auswahl eines älteren Tags zeigt vor dem Anwenden eine Downgrade-Warnung. In jedem Fall ist die Änderung ein ServiceUpdate / Rolling Update, hinter einer Bestätigung. Liefert die Registry überhaupt keine Tags und gibt es auch kein konkretes Ziel — eine private oder nicht erreichbare Registry oder ein per Digest gepinnter Service —, bekommst du einen erklärenden Hinweis, und es wird nichts geändert.

Jeder Service wird angezeigt (auch einer, der auf null skaliert ist), jede Zeile gerendert wie eine docker service ls-Zeile — Name, Modus, laufende/gewünschte Anzahl, Image und veröffentlichte Ports — und danach eingefärbt, wie es dem Service tatsächlich geht: Die laufenden/gewünschten Tasks geben die Grundfarbe vor (aqua = alle Tasks oben, orange = teilweise, rot = unten, grau = auf null skaliert), ein fehlschlagender Healthcheck überschreibt sie (siehe unten). Ein ▸/▾-Marker zeigt, ob ein Service eingeklappt oder ausgeklappt ist; seine laufenden Container verschachteln sich darunter. Ein Service mitten in einem Rolling Update trägt ein farbiges Badge in seiner Baumzeile — ⟳ updating oder ↺ rolling back — und derselbe Status erscheint im Service-Inspect-Overlay; es verschwindet, sobald das Update abgeschlossen ist.

Eingefärbt nach Healthcheck, nicht nur nach Replica-Zahl. Die Farbe einer Service-Zeile kam bisher allein aus laufend gegen gewünscht — ein Service, dessen sämtliche Container ihren Healthcheck rissen, stand also weiterhin als ruhiges aquafarbenes 3/3 da. Die Zahl stimmte, die Zeile log. Der Task-Status von Swarm hilft hier nicht weiter: Eine Task ist running, während ihr Container jede Probe verfehlt — das Urteil muss also vom Node kommen. Eine fehlschlagende Probe gilt jetzt als Verschlechterung derselben Art wie ein fehlendes Replica:

• alle geprüften Container unhealthy → die Zeile wird rot, das ist so schlimm wie „läuft keiner“;
• ein Teil unhealthy → orange, wie bei einem halb ausgerollten Update;
• alle healthy → die Farbe, die die Replica-Zahl der Zeile ohnehin gegeben hat, unverändert;
• Container ohne Healthcheck → die Zeile wird gar nicht umgefärbt. Über sie ist nichts bekannt, und Raten wäre derselbe Fehler in die andere Richtung.

Die Marker. Eine Service-Zeile trägt ✖ N unhealthy in Rot oder ◌ N starting in Gelb, solange die Proben noch nicht durch sind; ein Container-Blatt trägt ✖ unhealthy bzw. ◌ starting. Unhealthy sticht starting — das ist das, wo man ran muss. Eine Stack-Zeile fasst denselben Marker über alles darunter zusammen (siehe Nach Stack gruppiert weiter unten). Ein gesunder Container bekommt keinen Marker, einer ohne Healthcheck ebenso wenig; so bleibt der Marker eine Aussage. Sie stehen neben den cpu/mem-Ressourcenmarkern weiter unten, und die Gesundheit kommt in der Zeile zuerst: Sie ist das, was der Zahl direkt daneben widerspricht.

Marker für die tatsächliche CPU- und Memory-Nutzung. Neben diesen Badges kann eine Zeile auch zeigen, was sie gerade wirklich verbraucht — bisher konnte swarmexec nur anzeigen, was der Scheduler gebucht hat (siehe den Nodes-Tab weiter unten). Überschreitet ein Container oder ein Service 70 %, bekommt er einen orangen Marker, ab 90 % einen roten — am Ende der Zeile, mit der Ressource in Worten (cpu für CPU, mem für Memory) und dem Prozentwert (cpu 94 %, mem 91 %). Sind beide heiß, erscheinen beide. Worte statt Symbolen, bei gleicher Breite: Ein Marker, dessen Bedeutung man erst nachschlagen muss, tut seinen Job nicht — und Buchstaben können in keinem Terminal an der Darstellung scheitern. Unter 70 % wird nichts gezeichnet, damit die Marker ein Signal bleiben und keine Tapete. Eine Service-Zeile nimmt den schlechtesten ihrer Replicas, nicht den Durchschnitt — ein Durchschnitt verdeckt genau den einen Container, der gleich stirbt, und der ist der interessante. (Der absolute Memory-Wert einer Service-Zeile ist die Summe über die Replicas, der Prozentwert das Maximum.)

Wovon der Prozentwert ein Prozentwert ist. Gemessen wird gegen das, was der Container tatsächlich nutzen darf: sein eigenes Limit, wenn er eins hat, sonst die Kapazität des Nodes. Genau darauf kommt es an — 91 % eines 256-MB-Limits heißt, ein OOM-Kill steht bevor; 91 % eines 64-GB-Nodes ist eine ganz andere Geschichte. Die Stats-Ansicht des Inspect-Overlays zeigt pro Container beide Seiten dieser Division und benennt die Bezugsgröße unter der Tabelle.

Nach Stack gruppiert. docker stack deploy versieht jeden Service, den es anlegt, mit dem Label com.docker.stack.namespace. swarmexec liest dieses Label aus der Service-Spec, die der Manager ohnehin schon geliefert hat — Swarm kennt kein Stack-Objekt, das Label ist die einzige Verbindung — und verschachtelt den Baum drei Ebenen tief: Stack → Service → Container. Eine Stack-Zeile zeigt den Stack-Namen, wie viele Services darunter hängen und die summierte laufende/gewünschte Task-Anzahl ((3 svc · 7/8)), eingefärbt nach genau derselben Regel wie eine Service-Zeile — der summierten laufend/gewünscht-Zahl, mit derselben Healthcheck-Übersteuerung darüber. Dahinter stehen die Sammelzähler, sobald sie nicht null sind: ⟳ n — Services in diesem Stack mitten in einem Rolling Update — 🛡 n — Services mit einem handlungswürdigen Sicherheitsbefund, dasselbe Schild, das die Service-Zeilen tragen — und danach der Health-Marker, ✖ N unhealthy oder ◌ N starting, summiert über jeden Container jedes Service im Stack. Auch ein zugeklappter Stack verrät so, ob darin etwas Aufmerksamkeit braucht. Gerade beim Health-Marker zählt das: Die Stack-Zeile ist die Ebene, die man zuerst überfliegt — ein trügerisches „läuft alles“ ist hier schlimmer als eine Ebene tiefer, nicht harmloser.

Services, die mit docker service create angelegt wurden, tragen kein Stack-Label; sie landen gesammelt unter (no stack), das immer zuletzt einsortiert wird und damit nie echte Stacks nach unten drängt. Nichts wird versteckt — jeder Service erscheint weiterhin genau einmal. Stacks werden nach Namen sortiert und starten ausgeklappt, sodass der gruppierte Baum dieselben Services zeigt wie der flache; von dir gesetzte Falten überleben die Auto-Aktualisierung.

Die Gruppierung ist standardmäßig an, greift aber erst, wenn mindestens ein Service im Cluster tatsächlich ein Stack-Label trägt — auf einem Cluster ohne Stacks sieht der Baum genau aus wie bisher, ohne sinnlosen (no stack)-Elternknoten. s schaltet zwischen gruppiertem Baum und flacher Service-Liste um (die Fußzeile führt es als s stacks); gibt es nirgends ein Stack-Label, sagt es das, statt einen identischen Baum neu zu zeichnen. Die Taste ist als stack_group in keys.yaml umbelegbar.

Die Suche (/) bleibt unverändert: der Filter greift weiterhin auf Service, Container und Node. Ein Stack, den der Filter leert, verschwindet aus dem Baum, und die Zähler jeder Stack-Zeile beschreiben, was tatsächlich darunter gelandet ist — sie folgen also dem Filter, statt weggefilterte Services anzupreisen.

Das Aktionsmenü bietet Logs, Bash, Sh, Shell as user… (fragt nach einem Benutzer/einer UID, wie docker exec -u — für Images, deren Standardbenutzer die benötigten Werkzeuge oder Rechte nicht hat) und Port forward (nicht verfügbare Shells werden nach einem Test ausgegraut). In der Suchleiste behält Enter den Filter und kehrt zur Liste zurück; Esc löscht den Filter und schließt die Leiste.

Sicherheitsrisiken (!). Bei jedem Abruf der Service-Liste lässt swarmexec eine Reihe kleiner statischer Analyzer über die Spec jedes Service laufen — über dieselbe Spec, die der Manager ohnehin schon geliefert hat. Es gibt also keinen zusätzlichen API-Aufruf, der Agent ist nicht beteiligt, und in deinen Containern wird nichts ausgeführt. Ein Service mit einem Befund, der Handlung verdient, wird im Service-Baum mit einem vorangestellten 🛡 markiert — in einem Slot fester Breite vor dem Namen, sodass die Schilde eine senkrechte Scan-Spalte bilden. ! öffnet das Sicherheitsrisiken-Overlay, und w darin schreibt einen clusterweiten Markdown-Bericht — der mehr abdeckt als das Overlay, weil er die Prüfungen ergänzt, die dem Cluster gehören und keinem Service.

Die acht Prüfungen, die es heute gibt. Zuerst die, die einen Service markieren können, am Ende die rein informativen:

Warum die informativen Prüfungen nie einen Service markieren. Erst ein Befund oberhalb von low — high oder medium — macht einen Service handlungsrelevant und setzt das 🛡 an seine Baumzeile. Die Low-Befunde (no-resource-limits, unpinned-image und „no user set“ aus root-user) treffen auf nahezu jeden Service in einem echten Cluster zu: ein Badge dafür würde fast jede Zeile mit einem Schild versehen und genau das Signal auf einen Blick zerstören, für das der Marker da ist. Unter den Tisch fallen sie trotzdem nicht — sobald ein Service wegen etwas anderem markiert ist, stehen seine Low-Befunde im Overlay bei den übrigen, also dort, wo sie sich wirklich zu lesen lohnen.

Das Overlay listet jeden markierten Service („N of M service(s) flagged · 8 checks“), nach Service gruppiert, jeden Befund in einer eigenen Zeile mit einem Schweregrad-Punkt — ● high, ● medium, ● low — einem kurzen Titel und einer einzeiligen Erklärung. Befunde stehen nach Schweregrad absteigend. Sobald ein Service wegen etwas Handlungsrelevantem markiert ist, werden auch seine rein informativen Low-Befunde aufgeführt. Ist der Service unter dem Cursor darunter, wird er vorab hervorgehoben und ins Bild gescrollt. Ist nichts markiert, sagt das Overlay das ausdrücklich und nennt jede Prüfung, die gelaufen ist („Checked: Docker socket mounted in, added Linux capabilities, host network, seccomp / AppArmor disabled, container user, secrets in environment variables, missing resource limits, unpinned image.“) — so sagt die Entwarnung auch, was sie abdeckt. Ist die Service-Liste noch nicht geladen, meldet es es wurde noch nichts gescannt, statt fälschlich Entwarnung zu geben. j/k scrollen, Esc (oder q, oder erneut !) schließt.

i öffnet ein Inspect-Overlay für den Node unter dem Cursor — auf einem Service zeigt es docker service inspect, und auf einem Container-Blatt das Swarm-Task-Inspect (die Sicht des Managers auf diese Instanz: State, Slot, Node, Container-ID, Container-Spec, Ressourcen und Statushistorie). Beide kommen vom Swarm-Manager. Das Overlay öffnet sich mit einer tabellarischen, operator-first Zusammenfassung mit Abschnitten, die nach operativer Relevanz geordnet sind — zuerst Netzwerke, Labels, Volumes/Mounts und Secrets (und Configs), dann Ports, Image, Modus, Env, Ressourcen, Placement und Update-Policy (plus State, Node und Container-ID bei einem Container/einer Task), mit IDs und Zeitstempeln zuletzt. Die erste Zeile des Overlays — innerhalb des Rahmens und fest über dem scrollenden Inhalt — ist eine Tab-Leiste, die seine drei Ansichten benennt: table 1   stats 2   raw json 3, die aktuelle in der Akzentfarbe. Sie hat dieselbe Form wie die Tab-Leiste des Hauptfensters — ein Label, gefolgt von der Ziffer, die es auswählt. 1, 2 und 3 springen direkt zu Tabelle, Stats und rohem Daemon-JSON, und t schaltet weiterhin reihum Tabelle → Stats → rohes JSON und wieder zurück. Der Footer-Hinweis lautet nur noch 1-3/t view, und der Rahmentitel wiederholt die aktuelle Ansicht nicht mehr — er heißt schlicht inspect service foo, denn die Leiste sagt bereits, wo du bist. Beachte, dass die tabellarische Ansicht die Task-Sicht des Managers ist, nicht ein vollständiges node-lokales docker container inspect des laufenden Containers — ein echtes Container-Inspect über den Agent ist geplant.

Die Stats-Ansicht. Die mittlere der drei zeigt die tatsächliche Ressourcennutzung — dieselben Messwerte, die auch den Baum markieren; das Öffnen kostet also keinen zusätzlichen Aufruf, und die Zahlen aktualisieren sich weiter, solange die Ansicht offen ist. Sie ist eine Tabelle, eine Zeile pro Container des Service (oder der eine Container eines Task-Inspects):

Eine Tabelle, weil ein nackter Prozentwert nicht lesbar ist, wenn man nicht ohnehin weiß, wie das Werkzeug misst — 94 % wovon? Jede Zelle bringt ihre eigenen Einheiten mit, 0.07 / 4.00 cores braucht also keine Legende, und der Prozentwert steht direkt neben der Zahl, von der er ein Prozentwert ist. Mehrere Replicas vergleicht man, indem man eine Spalte entlangliest, statt gestapelte Blöcke gegeneinanderzuhalten. Die Spalte HEALTH formuliert das Urteil in Worten — healthy, unhealthy, starting oder none für einen Container, der gar keinen Healthcheck deklariert. none und healthy sind mit Absicht zwei verschiedene Worte und nicht ein Wort und eine Lücke: „kein Healthcheck konfiguriert“ und „die Probe läuft durch“ sind verschiedene Tatsachen, und eine Lücke läse sich wie das Zweite. Ein Container, den kein Agent gemeldet hat — nicht erreichbarer Node, ein für den Stats-RPC zu alter Agent oder ein erst seit der letzten Messung laufender Container —, zeigt in beiden Ressourcenspalten no reading statt einer Null, die sich wie „im Leerlauf“ läse.

Die Fußnote unter der Tabelle benennt den Nenner: das eigene Limit des Containers, wenn er eins hat, sonst die Kapazität des Nodes. Genau das macht einen Prozentwert erst aussagekräftig — 85 % eines 8-GiB-Limits und 85 % eines 64-GiB-Nodes sind zwei verschiedene Geschichten. Memory steht in binären Einheiten (MiB/GiB), denselben, die auch das Node-Detail verwendet und die docker selbst meldet; dieselbe Zahl liest sich also nie an zwei Stellen unterschiedlich. Bei mehr als einem gemessenen Container kommt unter der Tabelle eine Zusammenfassung dazu: CPU und Memory des schlechtesten Replicas — nicht der Durchschnitt, der genau den einen Container verdeckt, der gleich OOM-gekillt wird — plus das gesamte Memory über alle. Der t-Eintrag im ?-Hilfe-Overlay lautet entsprechend cycle table / stats / raw JSON.

Das Overlay ist navigierbar und auswählbar, nicht nur ein einfaches Scrollen: Datenzeilen sind einzeln auswählbar und du bewegst den Cursor Zeile für Zeile mit ↑/↓ oder j/k (Abschnittsüberschriften und Leerzeilen werden übersprungen). y kopiert die ausgewählte Zeile immer über OSC52 in deine Zwischenablage — derselbe Yank-Mechanismus, der auch anderswo verwendet wird — sodass du eine einzelne ID, einen Mount oder eine Adresse greifen kannst, ohne Text von Hand zu markieren. Enter kopiert ebenfalls, außer auf einer einklappbaren NETWORKS-Zeile, wo es stattdessen diese Zeile aus-/einklappt (siehe unten). Alle drei Ansichten (die tabellarische Zusammenfassung, die Stats-Ansicht und das rohe JSON, erreichbar über 1–3 oder reihum mit t) sind Zeile für Zeile auswählbar und kopierbar. Ein Footer listet immer die verfügbaren Tasten, sodass auf einen Blick sichtbar ist, was du tun kannst; bei einem Service zeigt der Footer auch die untenstehenden Bearbeitungstasten.

Der NETWORKS-Abschnitt ist einklappbar und beantwortet schon eingeklappt die Frage „unter welcher Adresse ist das erreichbar“: jedes angeschlossene Netzwerk erscheint als eingeklappte Zeile + <network> 🔒 vip 10.0.5.2/24 (2 dns names). Ein 🔒-Schlosssymbol nach dem Netzwerknamen markiert ein verschlüsseltes Overlay-Netzwerk (Data-Plane-Verschlüsselung, --opt encrypted); sein Fehlen bedeutet unverschlüsselt. Bei einem Service-Inspect heißt die Adresse vip — die virtuelle IP des Service in diesem Netzwerk, die Adresse, auf der der Swarm-Load-Balancer antwortet, gelesen aus dem ServiceInspect des Managers (Endpoint.VirtualIPs). Bei einem Container/Task-Inspect heißt sie addr: die eigene Adresse dieses Containers dort. Ein Service im Endpoint-Modus dnsrr hat überhaupt keine VIP — das ist so gewollt und kein fehlender Wert —, deshalb steht statt einer Lücke im ausgeklappten Netzwerk die Zeile no vip — dnsrr endpoint mode, the DNS name resolves to the containers. Das ingress-Netzwerk steht ebenfalls hier, obwohl es in keiner Spec vorkommt — Swarm hängt den Service von sich aus daran (siehe unten). Es wird hinter den Netzwerken aus der Spec angehängt, nie zwischen sie gemischt, und seine Kopfzeile lautet + ingress vip 10.0.0.250/24 (routing mesh): der Hinweis (routing mesh) steht dort, wo eine DNS-Namen-Zählung nur (0 dns names) ergeben könnte.

Geh auf eine Netzwerkzeile und drücke Enter, um sie aus- oder einzuklappen. Ausgeklappt listet sie die DNS-Namen auf, die auf den Service/Container in diesem Netzwerk auflösen — den Service-Namen, tasks.<service> und alle benutzerdefinierten Aliase —, sodass du sehen kannst, unter welchem DNS-Namen er erreicht wird und welche Aliase er pro Netzwerk trägt. Darunter steht eine zweite einklappbare Zeile, + 2 containers (im Singular + 1 container); Enter darauf öffnet die tiefste Ebene: eine spaltenbündige Zeile pro Container, web.1 10.0.1.5/24 host-a — Task-Name, seine Adresse in diesem Netzwerk und der Node, auf dem er läuft (replizierte Tasks heißen <service>.<slot>, globale <service>.<node>, da sie keinen Slot haben).

Gefiltert wird dabei über den Soll-Zustand (desired state) der Task, nicht über ihren aktuellen: gelistet wird jede Task, die der Manager weiterhin laufen lassen will — auch solche, die erst preparing, assigned oder starting sind. Sie halten ihre Adresse bereits, und während eines Rolling Updates sind das die meisten; ein Filter auf den aktuellen Zustand würde den Drilldown also genau dann leeren, wenn er am interessantesten ist. Eine Task, die der Manager aufgegeben hat — Soll-Zustand shutdown, also durch ein Rolling Update ersetzt, weggeskaliert oder fehlgeschlagen —, erscheint nicht: ihre Adresse ist wieder freigegeben und kann längst einem anderen Container gehören, sie zu zeigen wäre also aktiv falsch. Eine Task, die noch keinen Traffic bedient, trägt ihren Zustand in Klammern am Zeilenende, web.1 10.0.1.5/24 host-a (starting); eine laufende hat kein Suffix. Die Zeilen stammen aus einem TaskList der Manager-API, gefiltert auf den Service, und sind Best-Effort — ein API-Fehler lässt den Drilldown einfach leer. Die beiden Ebenen klappen unabhängig voneinander; klappst du das Netzwerk ein, verschwindet die Container-Ebene mit.

Die ingress-Zeile ist diejenige, die in keiner Spec steht: Swarm hängt einen Service von sich aus an das ingress-Netzwerk, sobald er einen Port im Modus ingress veröffentlicht. Diese Anbindung taucht in der Service-Spec nirgends auf — ihre vip ist aber genau die Adresse, auf der das Routing Mesh tatsächlich antwortet, und das ist das Erste, was du wissen willst, wenn ein veröffentlichter Port sich merkwürdig verhält. Deshalb bekommt sie eine eigene Zeile, angehängt hinter den Netzwerken aus der Spec und leicht anders geformt: auf ingress löst kein Service-DNS-Name auf, deshalb trägt diese Kopfzeile dort, wo andere Netzwerke ihre Namen zählen, den Hinweis (routing mesh). Ausgeklappt listet sie stattdessen die über ingress veröffentlichten Ports auf, die den Service überhaupt dorthin gebracht haben — der Grund für die Zeile —, je eine Zeile pro Port: published 2222 -> 22/tcp. Ports, die im Modus host veröffentlicht sind, umgehen das Routing Mesh und werden dort bewusst nicht aufgeführt. Darunter geht es genauso in die Tiefe wie bei jeder anderen Netzwerkzeile: dieselbe Ebene + 1 container, mit der eigenen Adresse jedes Containers im ingress-Netzwerk. Ein Service, der keinen Port über ingress veröffentlicht, hat dort keine VIP — und damit auch keine solche Zeile.

Ein GitLab-Service, der SSH auf 2222 veröffentlicht, beide Ebenen ausgeklappt:

Kopieren innerhalb von NETWORKS liefert die Adresse ohne Maske — 10.0.5.2, die Form, die du in ein curl oder ping einfügst: auf einer Netzwerkzeile deren vip/addr, auf einer Container-Zeile die Adresse dieses Containers. Eine Netzwerkzeile ohne Adresse (dnsrr) kopiert wie bisher den Netzwerknamen. Auf beiden Arten einklappbarer Zeilen schaltet Enter um; auf jeder anderen Zeile kopiert es (und y kopiert immer).

Wenn du einen Service inspizierst (nicht ein Container/Task-Blatt, dessen Overlay schreibgeschützt bleibt), stellt der Overlay-Footer auch mehrere Bearbeitungstasten bereit, jede ein Manager-API-ServiceUpdate, das ein Rolling Update / eine Rekonziliation der Tasks des Service auslöst.

Fang mit a an — dem Aktionsmenü. Im Service-Inspect (nur dort) öffnet a eine einzige Liste mit jedem Editor und jeder Aktion, die das Overlay bietet — so musst du dir keine ~14 Tasten mit Groß-/Kleinschreibung merken (d/D, s/f, p/l/e, n/S/v, r/P, R, X). Das ist der auffindbare Weg ohne Shift — und kein abgespeckter: ein Eintrag schließt das Menü und öffnet genau das, was auch die direkte Taste öffnet, beide sind also gleichwertig und keine Varianten mit unterschiedlichem Verhalten. Die Einträge in ihrer Reihenfolge: Update image version… (Set image version…, wenn es keine neuere gibt — auf einen Tag deiner Wahl pinnen oder zurückgehen ist genauso legitim), 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 — der destruktive, deshalb rot markiert — und Cancel. Navigiert wird mit j/k (g/G springen zum ersten/letzten Eintrag), Enter wählt aus; Esc — oder der Eintrag Cancel — schließt das Menü, ohne etwas zu tun. Die Image-Versionsauswahl steht an erster Stelle, weil eine Version zu setzen die gewöhnlichste Service-Änderung überhaupt ist; ihre direkte Taste u funktioniert weiterhin aus jeder Zeile des Inspect. Ist das Image eines, für das sich keine Version wählen lässt — eine Referenz ohne Tag, oder eine Registry, die die Tags des Repos nicht herausgibt, typischerweise eine private ohne Zugangsdaten —, bleibt der Eintrag in der Liste und sagt das, statt stillschweigend zu verschwinden, und verweist auf das docker service update --image, das funktioniert. Die direkte Taste zu jedem Eintrag:

Diese Editoren sind gestagt: a fügt einen Eintrag hinzu, d löscht den unter dem Cursor, y kopiert den ausgewählten Eintrag über OSC52 in deine Zwischenablage (sodass du z. B. eine einzelne Umgebungsvariable greifen kannst, während du sie ansiehst), u macht die letzte gestagte Änderung rückgängig (Hinzufügen / Bearbeiten / Löschen), solange du noch nicht angewendet hast — drücke es wiederholt, um schrittweise durch die gestagte Historie zurückzugehen — und w wendet alle Änderungen auf einmal in einem einzigen ServiceUpdate an (sodass z. B. das Hinzufügen mehrerer Volumes und anschließendes Drücken von w ein Rolling Update auslöst, nicht eines pro Eintrag), hinter einer Bestätigung. Wenn du Esc drückst, während noch Änderungen gestagt sind, verwirft der Editor sie nicht stillschweigend — er fragt, ob anwenden, verwerfen oder weiter bearbeiten. Solange Änderungen noch gestagt sind, werden sie hervorgehoben, sodass du genau siehst, was sich ändern wird: hinzugefügte oder bearbeitete Einträge erscheinen in Grün (neu) und entfernte Einträge bleiben als gedimmte rote „removed“-Zeilen stehen — die Hervorhebung verschwindet, sobald du anwendest. Die Editoren für Ports, Labels, Mounts, Env und Aliase (Aliase über A aus dem Netzwerk-Editor erreicht) haben außerdem e, um den Eintrag unter dem Cursor zu bearbeiten; die Editoren für Netzwerke und Secrets haben kein e — ein Netzwerk- oder Secret-Eintrag ist nur ein Name, also nur Hinzufügen (a) / Entfernen (d). Das e des Env-Editors öffnet einen scrollbaren mehrzeiligen Textbereich (Ctrl-S speichern / Esc abbrechen) für lange Werte; die übrigen Editoren behalten die einzeilige Eingabe mit Enter zum Bestätigen.

Der Baum aktualisiert sich automatisch alle ~10s, sodass ein im Hintergrund ersetzter Container oder ein skalierter Service von selbst auftaucht — der Cursor und alle ausgeklappten Services bleiben erhalten. r erzwingt weiterhin eine sofortige Aktualisierung.

Volumes-Tab

Das Löschen ist node-bewusst: ein Volume wird auf jedem Node entfernt, der es hält. Prune verschont Volumes, die ein Service deklariert, selbst wenn keine Task läuft, sodass es die Daten eines gestoppten Stacks nicht löscht. Für feinere Kontrolle öffnet Enter die Liste pro Node, wo space Nodes auswählt, d die Kopie des markierten Nodes löscht und a auf allen Nodes löscht — jeweils hinter einer Bestätigung.

Forwards-Tab

Ein laufender Container wird im Baum als local→remote annotiert (z. B. 9090→8080). Forwards laufen weiter, wenn ihr Overlay schließt und wenn du auf einen anderen Cluster wechselst; sie stoppen bei d oder wenn du die UI beendest. Die CLUSTER-Spalte nennt den Context, zu dem jeder gehört, gedimmt für den gerade sichtbaren — ein Forward auf einem anderen Cluster ist weiterhin deiner und lauscht weiter, aber sein CONTAINER und NODE benennen Dinge, die du von hier aus nicht sehen kannst. Die Baum-Annotation ist aus demselben Grund pro Cluster: eine Container-ID ist nur innerhalb ihres eigenen Daemons eindeutig.

Deshalb wird ein lokaler Port, den du schon benutzt, vorab abgelehnt — mit Angabe des Forwards, der ihn hält, und des Clusters, zu dem er gehört; der Prompt bleibt offen, damit du einen anderen Port wählen kannst. Das „address already in use" des Betriebssystems bleibt für den Fall, in dem es recht hat: ein Port, den ein anderes Programm hält und den swarmexec nicht benennen kann.

Networks-Tab

Eine Liste der Netzwerke des Swarms — Name, Driver, Scope, Typ (ingress / internal / attachable), ob das Netzwerk verschlüsselt ist und wie viele Services an jedes angeschlossen sind. Die TYPE-Spalte zeigt overlay oder den Driver-Namen (z. B. bridge) für einfache Netzwerke statt eines Strichs. Die ENC-Spalte zeigt 🔒 yes, wenn das Overlay-Netzwerk Data-Plane-Verschlüsselung an hat (erstellt mit --opt encrypted), sonst einen Strich. Der Name jedes Netzwerks und seine TYPE-Zelle sind nach Art farbcodiert (höchste Priorität zuerst):

• attachable — grün
• internal — gelb
• ingress — grau
• anderes Overlay / swarm-scoped — aqua
• lokal (bridge, host, …) — gedimmtes Grau

Anhängen oder Trennen macht ein Service-Update, das das Netzwerk in der Service-Spec hinzufügt oder entfernt, und aktualisiert dann den Networks-Tab. Das ist eine Manager-API-Operation (ServiceUpdate) — derselbe Kanal, den der Client für die Topologie nutzt — und sie löst ein Rolling Update aus, das die Tasks des Service neu startet.

Secrets-Tab

Eine schreibgeschützte Liste der Secrets des Swarms — Name, wie viele Services jedes verwenden, Alter, letzte Aktualisierung und Label-Anzahl. Secret-Werte werden nie angezeigt: die Docker-API legt sie nicht offen.

Das Anhängen fügt das Secret dem Service hinzu, eingehängt unter /run/secrets/<name> (wie docker service update --secret-add); das Trennen entfernt die Secret-Referenz. Dann aktualisiert sich der Secrets-Tab. Wie beim Netzwerk-Anhängen/-Trennen ist jedes ein Manager-API-ServiceUpdate, das ein Rolling Update auslöst, das die Tasks des Service neu startet.

Context-Sidebar

Die Cluster stehen in einer Spalte am rechten Rand, nicht in einem Tab. Den Cluster zu wechseln ist etwas, das man von dort aus tut, wo man gerade ist — und die Liste der Cluster ist das, was einem sagt, wo das ist. Sie gehört also auf den Bildschirm und nicht auf eine Seite, zu der man erst hinreisen muss.

c gibt ihr aus jedem Tab die Tastatur; c erneut oder Esc gibt sie an den Tab zurück, auf dem du warst. Der aktive Cluster ist mit ▶ markiert — derselbe Name, den der Footer zeigt. Ein Cluster, den du in dieser Sitzung schon besucht hast, trägt ein grünes ·: er ist noch verbunden, der Wechsel dorthin ist sofort da. Einer, der die Verbindung verweigert hat, trägt ein rotes ✗. Der eingebaute default-Context ist geschützt.

Die Sidebar richtet ihre Breite nach dem längsten Context-Namen und tritt auf schmalen Terminals beiseite: unter etwa 92 Spalten blendet sie sich aus, statt den Baum abzuschneiden, und kommt zurück, solange c sie hält. Endpoints stehen nicht in der Spalte — dort ist kein Platz dafür, und i zeigt das vollständige Detail.

Ein Cluster-Wechsel behält deine Sitzung. Die UI baut sich nicht neu auf: wo der Cursor stand, welche Stacks und Services aufgeklappt waren und der /-Filter werden pro Cluster gemerkt — du landest also wieder genau dort, wo du aufgehört hast. Port-Forwards laufen weiter; der Forwards-Tab bekommt dafür eine CLUSTER-Spalte, damit auf einen Blick klar ist, welche zum gerade sichtbaren Cluster gehören und welche nicht.

Gepollt wird nur der Cluster, den du ansiehst: beim Wegschalten hört der andere auf zu aktualisieren, und seine ssh-Verbindung läuft kurz darauf von selbst aus. Der erste Wechsel zu einem Cluster dauert so lange, wie ihn zu erreichen dauert — die Verbindung wird aufgebaut, bevor sich auf dem Bildschirm etwas ändert. Scheitert sie, erfährst du, welcher Cluster es war, und bleibst auf dem, der funktioniert. Jeder weitere Wechsel zurück ist sofort da.

Nodes-Tab

Listet die Nodes des Swarms mit allgemeinen Infos und ein paar Aggregationen — NODE (Hostname; Manager in aqua, der Leader markiert mit ★), ROLE (manager / worker), AVAIL (active / pause / drain, farbcodiert), STATE (ready / down), ENGINE-Version, TASKS (auf dem Node eingeplante laufende Tasks), VOLS (Volumes, die der Node hält — node-lokal, füllt sich daher einen Moment nach dem Rest) und LABELS (Anzahl).

Reservierte Ressourcen. Die Node-Details enthalten einen Block reserved by tasks (scheduler's view): je für CPU und Memory einen Balken plus reserviert / Kapazität und wie viel frei ist. Der Balken ist grün, wird ab 75 % gelb und bei 100 % oder darüber rot; eine Überbuchung wird ausdrücklich benannt, und „frei“ wird nie negativ. Ein Node, der keine Kapazität meldet, sagt das, statt einen Balken zu zeichnen. Der Block kostet keinen zusätzlichen API-Call — die Node-Liste holt die Task-Liste ohnehin.

Tatsächlich von Containern genutzt. Darunter steht ein zweiter Block — in use by containers (measured on the node) — mit denselben proportionalen Balken: was die Container des Nodes gerade wirklich verbrauchen, CPU in Cores und Memory, jeweils gegen die Kapazität des Nodes. Die beiden Blöcke bleiben bewusst getrennt, denn sie beantworten verschiedene Fragen und liegen regelmäßig weit auseinander: Ein Node kann voll gebucht und trotzdem im Leerlauf sein — oder kaum gebucht und am Limit. Die Zahlen kommen vom Agent dieses Nodes, derselben Quelle wie die Nutzungsmarker im Service-Baum — solange die CPU-Differenz noch nicht vorliegt, steht dort measuring…, und ein Node, dessen Agent nicht erreichbar oder zu alt ist, bekommt gar keinen Block statt einer Reihe Nullen, die wie „im Leerlauf“ aussähe.

Images auf diesem Node. Zuletzt steht in den Details ein Block images on this node: wie viel der Layer-Store des Nodes belegt und in wie vielen Images, und wie viel davon in ungetaggten Überbleibseln freigeräumt werden kann (ein Node ohne ungetaggte Images sagt das, statt eine Null anzubieten). Gibt es darüber hinaus etwas, kommt eine weitere Zeile dazu: wie viel zusätzlich getaggt, aber ungenutzt ist — bewusst als Kosten formuliert, das Entfernen bedeutet, diese Images wieder zu ziehen, und nicht als Angebot. Den Block gibt es, weil Images die eine node-lokale Ressource sind, die von der Cluster-Seite überhaupt nicht zu sehen ist: Die Manager-API hat keinerlei Sicht auf Images — anders als bei Volumes, von denen sie immerhin weiß, dass sie gemountet sind. Volumes ließen sich aus swarmexec längst clusterweit verwalten; ein Node, dessen Platte still mit alten Layern volllief, war nicht einmal sichtbar. Der Block lädt eigenständig, parallel zur Node-Liste, und erscheint daher einen Moment nach dem Rest des Overlays.

Freiräumen — P im Nodes-Tab. Das Menü dahinter hat zwei Einträge, bewusst keine Aktion mit Checkbox, denn es sind zwei verschiedene Handlungen, und eine Checkbox lädt dazu ein, versehentlich die zerstörerische zu erwischen:

Zwei Modi, zwei Berechtigungen. Der Agent autorisiert sie als zwei eigenständige Aktionen — image.prune für die ungetaggten Überbleibsel und image.prune.all für den Rundumschlag —, sodass eine Policy das Freiräumen ungetaggter Layer erlauben kann, ohne den zerstörerischen Modus mit zu erlauben. Jedes Prune landet im Audit-Log des Agents: mit welchem Modus, wie viel freigeräumt wurde und wie viele Images gegangen sind.

Dieselbe Voraussetzung wie bei den Nutzungs- und Health-Zahlen oben: Es braucht Agents aus diesem Release oder neuer. Ein Node mit älterem Agent zeigt schlicht gar keinen Image-Block und meldet auf P, dass er nicht geantwortet hat — ausrollen mit swarmexec init --force.

Configs-Tab

Tab 8 — das Gegenstück zum Secrets-Tab für das andere Objekt, das der Swarm in Container reicht, mit einem entscheidenden Unterschied: der Inhalt eines Configs ist lesbar. Der Secrets-Tab kann einen Wert nie zeigen (die Docker-API gibt ihn nicht heraus); die Config-Detailansicht zeigt den tatsächlichen Inhalt, sodass du siehst, was ein Service wirklich bekommt, ohne auf docker config inspect auszuweichen. Genau darum geht es in diesem Tab.

Die Liste ist schreibgeschützt: CONFIG (Name), USED BY (wie viele Services es einhängen), SIZE, AGE, UPDATED und LABELS (Anzahl).

Der Inhalt wird bei Bedarf geholt, wenn die Detailansicht aufgeht — nicht zusammen mit der Liste — denn ein Config kann eine ganze nginx.conf sein; bis dahin steht dort loading…, ein leeres Config meldet (empty). Gezeigt wird eine Vorschau, begrenzt sowohl auf 64 KiB als auch auf 500 Zeilen. Beide Grenzen sind nötig: Begrenzt man nur die Bytes, kann eine Datei aus sehr kurzen Zeilen immer noch zu Zehntausenden gerenderten Zeilen werden — jede zusätzlich eingerückt — und genau das lässt die Ansicht kriechen. Eine Kürzung wird immer benannt („… truncated at 500 lines“ bzw. an der Byte-Grenze), nie still abgeschnitten, und binärer Inhalt wird gemeldet, nicht ausgekippt („(binary content, N — not shown)“, erkannt an NUL-Bytes im Kopf der Daten). Das vollständige Config ist ein docker config inspect entfernt.

USED BY wird genauso hergeleitet wie im Secrets-Tab: Der Swarm führt keinen Rückwärtsindex von einem Config zu seinen Nutzern, also liest swarmexec die Service-Specs (ein ServiceList) und erkennt eine Referenz an der ID oder am Namen des Configs — eine Spec kann beide Formen enthalten, deshalb werden beide nachgeschlagen und zusammengeführt. Best effort: Lässt sich die Service-Liste nicht lesen, erscheinen die Configs trotzdem, nur ohne Zuordnung.

Eingebettete Shell & Logs

In einer eingebetteten Shell löst Ctrl-] ab (ohne den Prozess zu beenden). Die Logs-Ansicht — ein einzelner Container oder die aggregierten Logs eines Service — unterstützt dasselbe formatbewusste Parsen und Filtern wie der logs-Befehl:

Die Ansicht rendert die gepufferten Zeilen live neu, wenn du Format, Stufe oder Grep änderst, und die Titelleiste zeigt den aktiven Status fmt:… lvl:… grep:….

Beim Folgen verbindet sich die Log-Ansicht über Container-Ersetzung hinweg neu, genau wie es der logs-Befehl tut — sowohl für die Logs eines einzelnen Containers als auch für die aggregierten Logs eines Service (jedem Replica nach Slot gefolgt). Reconnect-Hinweise erscheinen inline in der Log-Ansicht.

Log-Viewer

Drücke ` (Backtick) von jedem Tab aus, um ein Live-Log-Overlay umzuschalten. Es zeigt die neuesten Einträge aus dem In-Memory-Ringpuffer — neueste unten — aktualisiert sich, während es offen ist, und ist nach Stufe farbcodiert (rot = error, gelb = warn, grau = debug). ↑/↓ scrollen; Esc, q oder ` schließen es. Das ist das Fenster der TUI auf dieselben Logs, die in die Log-Datei gehen, da das Terminal sie selbst nicht anzeigen kann, während die UI zeichnet.

Eigene Tasten

Die Shortcut-Tasten sind in ~/.config/swarmexec/keys.yaml umbelegbar (neben config.yaml; überschreibe den Pfad mit $SWARMEXEC_KEYS). Jeder Wert ist eine einzelne Taste oder das Wort space. Die strukturellen Tasten — Enter, Esc, Tab, die Pfeile, die Tab-Nummerntasten 1–8 und die vim-Aliase j/k/g/G — sind fest. Der Footer zeigt immer deine tatsächlichen Tasten, und das ?-Overlay listet sie alle auf.

Das Laden schlägt nie fehl: eine ungültige oder reservierte Taste, eine unbekannte Aktion oder zwei Aktionen, die auf einem Tab an dieselbe Taste gebunden sind, fallen jeweils auf den Standard zurück, und die UI zeigt die Warnungen einmalig beim Start.

11. Exit-Codes