e1s 2.0.0: ECS im Terminal steuern statt in der AWS-Konsole klicken

Hallo, hier ist wieder Kora. Wer regelmäßig mit Amazon ECS arbeitet, kennt das Ritual: Browser auf, Konsole laden, Region prüfen, Konto wechseln, wieder von vorn. Genau dagegen tritt e1s an – und Version 2.0.0 macht das Terminal-Tool spürbar alltagstauglicher.

Was e1s eigentlich ist

e1s ist ein quelloffenes Terminal-Werkzeug, mit dem sich ECS-Ressourcen navigieren und verwalten lassen – konzeptionell angelehnt an k9s, das viele von uns aus der Kubernetes-Welt kennen. Es funktioniert sowohl mit Workloads auf Fargate als auch auf EC2 und speichert selbst keine Zugangsdaten, sondern greift auf die lokale AWS-CLI-Konfiguration zurück. Laut Projektdokumentation kommen dabei auch Assume-Role-Profile, credential_process und das AWS IAM Identity Center zum Zug.

Diesen Punkt finde ich aus Security-Sicht wichtig: Ein Tool, das keine eigene Credential-Haltung erfindet, sondern die bestehende Kette nutzt, reduziert die Angriffsfläche und passt in vorhandene Rollen- und Rechtekonzepte. Wer ohnehin mit kurzlebigen Sessions über Identity Center arbeitet, muss dafür keine Sonderlocke bauen.

Kontextwechsel im laufenden Betrieb

Das Highlight der neuen Version ist der Wechsel von AWS-Profilen und Regionen mitten in der Sitzung – laut Projekt über Ctrl+P beziehungsweise Ctrl+R. Bisher war so ein Kontextwechsel meist mit einem Neustart des Tools oder anderen Umgebungsvariablen verbunden, beziehungsweise mit Startparametern wie --profile und --region.

Klingt nach einer Kleinigkeit, ist es im Alltag aber nicht. Teams, die getrennte Profile für Entwicklung, Test und Produktion pflegen oder Cluster über mehrere Regionen verteilt betreiben, springen ständig zwischen Kontexten hin und her. Jeder Neustart kostet nicht nur Sekunden, sondern auch den mentalen Faden – und erhöht die Chance, versehentlich im falschen Konto zu landen. Ein sichtbarer, bewusst ausgelöster Wechsel im Tool ist da die sauberere Lösung.

Suchen und Sortieren, das den Refresh überlebt

Die Tabellenansichten lassen sich jetzt durchsuchen und sortieren – und, das ist der eigentliche Fortschritt, Filter und Sortierung bleiben beim automatischen Aktualisieren erhalten. Wer schon einmal in einem größeren Cluster nach einem bestimmten Service gefiltert hat und dann nach jedem Refresh die Eingabe wiederholen durfte, weiß, wie nervig das ist. Der Changelog nennt außerdem eine allgemein verbesserte Zuverlässigkeit.

Zwei Wege in den Container: ECS Exec oder SSM

Für das Ausführen von Befehlen in Containern bietet e1s 2.0.0 einen konfigurierbaren Ausführungsmodus mit den Werten ecs und ssm – also ECS Exec oder AWS Systems Manager. ECS Exec ist dabei die ECS-eigene Variante, um interaktiv Kommandos in einem laufenden Container abzusetzen oder eine Shell zu öffnen. Der praktische Nutzen: Im Störungsfall kommt man an Diagnoseinformationen heran, ohne einen eingehenden Port zu öffnen oder SSH-Schlüssel verwalten zu müssen. AWS unterstützt das sowohl für Container auf EC2 als auch auf Fargate.

Aus Betreibersicht ist genau das der Punkt, den ich hervorheben würde: Debugging-Zugriff ohne offene Ports und ohne Schlüsselverwaltung ist ein echter Sicherheitsgewinn. Jeder nicht existierende SSH-Zugang ist einer, der nicht kompromittiert werden kann.

ECS Managed Daemons

Neu dazugekommen ist die Unterstützung für ECS Managed Daemons. Dabei stellt ECS sicher, dass auf jeder EC2-Instanz eines zugeordneten Managed-Instances-Kapazitätsproviders genau ein Daemon-Task läuft. Anders als ein regulärer Service skaliert so ein Daemon also nicht auf eine frei wählbare Task-Zahl, sondern folgt dem Bestand der Instanzen. Typische Kandidaten dafür sind Aufgaben, die pro Host genau einmal existieren sollen. Dazu kommen Verbesserungen bei Service-Updates und bei der Auswahl von Task-Definitionen.

Unser Blick darauf

Der Trend zu Terminal-UIs für Cloud-Ressourcen hält sich hartnäckig – und das aus gutem Grund. Wer täglich mit Infrastruktur arbeitet, ist mit Tastatur und Textoberfläche schlicht schneller unterwegs als mit einer Webkonsole, die bei jedem Kontextwechsel neu lädt. Zusätzlich lassen sich solche Werkzeuge in Bastion-Hosts oder Jump-Umgebungen betreiben, wo ein Browser gar nicht erwünscht ist.

Eine Einschränkung möchte ich trotzdem erwähnen: Ein komfortables Werkzeug ersetzt keine Automatisierung. Änderungen an produktiven Services gehören weiterhin in Infrastructure-as-Code und in nachvollziehbare Pipelines. e1s sehe ich vor allem als Beobachtungs- und Diagnosewerkzeug – und in dieser Rolle macht es einen ziemlich guten Eindruck.

Bis demnächst, eure Kora

Quelle: heise online