Flotten-Dashboard

Container-Überwachung über die gesamte Rogue-AI-Flotte

Gebaut von Rogue AI · Container-Überwachung der selbst gehosteten Flotte auf einer Oberfläche · Internes Werkzeug

Schrittweise mit der wachsenden Flotte gebaut; täglich als Betriebskonsole im Einsatz.

Flotten-Dashboard, Container-Überwachung über die gesamte Rogue-AI-Flotte

Das Problem

Die Flotte wuchs auf rund sechzig Container, verteilt über getrennte Apps, jede in ihrem eigenen Netzwerk und mit eigenen Ports, eigener Datenbank und eigenem Redis. Den Zustand zu prüfen hieß, pro App docker ps auszuführen und Logs zu verfolgen und die gesamte Port- und Subnetz-Karte im Kopf zu behalten. Es gab keinen einzigen Ort für die Frage 'was läuft, was kämpft, und wo liegt es?'

Was ich gebaut habe

Ein Single-Page-Dashboard, das die gesamte Flotte auf einen Blick zeigt: Karten pro App mit farbcodiertem Zustandsabzeichen, CPU- und Speicherbalken, Datenbankgrößen und einem aufklappbaren Log-Betrachter. Es gruppiert rohe Container wieder zu den Apps, zu denen sie gehören, macht die app-übergreifende Port- und Subnetz-Karte sichtbar und lässt den Betreiber direkt von der Karte aus neu starten, neu bauen oder ein Image ziehen, wobei Datenbank-Container von diesen Aktionen bewusst ausgenommen sind.

Architektur

Next.js-Frontend hinter Authentifizierung

Das Dashboard und seine API-Routen sind eine Next.js-App, geschützt durch NextAuth v5. Sie berührt den Docker-Socket nie selbst, sie ruft nur den Sidecar über ein internes Netzwerk auf, sodass die öffentliche Oberfläche keinen privilegierten Zugriff hält.

Python-Flask-Sidecar für den Docker-Socket

Ein kleiner Flask-Dienst ist die einzige Komponente, die mit dem Docker-Socket spricht. Er zählt Container auf, liest Statistiken und Logs und führt Lebenszyklus-Aktionen aus. Der Socket ist nur lesend eingebunden, die API ist durch ein geteiltes Geheimnis gesichert, und der Container ist über keinen externen Port erreichbar.

Container zurück zu Apps gruppiert

Rohe Container-Namen sagen für sich genommen wenig aus, daher ordnet eine Metadatenschicht Container wieder der App zu, zu der sie gehören, und stellt eine Karte pro App dar, samt Port-Zuweisungen und eigenem Subnetz, statt einer flachen Liste.

Zwischengespeichertes Abfragen in festem Intervall

Statistiken und Container-Listen werden kurz im Sidecar zwischengespeichert, und das Dashboard aktualisiert sich in einem festen Intervall. Das verhindert, dass der Socket bei jedem Seitenaufruf belastet wird, und gibt dennoch einen nahezu aktuellen Zustand wieder.

Abgesicherte Lebenszyklus-Aktionen mit Audit-Spur

Neustart, Neubau und Pull laufen über den Sidecar mit Zeitlimits pro Aktion und werden mit Nutzer und Ergebnis protokolliert. Datenbank-Container sind per Name gesperrt, damit ein versehentlicher Klick Postgres oder Redis nicht durchstarten kann.

Tech-Stack

Next.jsNextAuth 5Python Flask sidecarDocker

Was zuerst gebrochen ist

▸
Das Lesen des Docker-Sockets ist ein privilegierter Vorgang und gehört deshalb nicht in die nutzerseitige Web-App. Wird er in einen eigenen Sidecar mit einer einzigen engen Aufgabe ausgelagert, bleibt der Schadensradius klein, falls das Frontend je kompromittiert wird.
▸
Eine einzige Zahl sagt mehr als eine Wand voller Diagramme. Meist lautet die einzige Frage 'ist alles grün?', also beantwortet das Dashboard genau das zuerst und hält das Detail pro Container einen Klick entfernt.
▸
Einige Dutzend Container bei jedem Seitenaufruf abzufragen reicht schon, um den Socket zu überlasten. Die Statistiken kurz im Sidecar zwischenzuspeichern und in einem festen Intervall zu erneuern hält den Host reaktionsfähig, ohne über den Zustand zu täuschen.

Ergebnis

Die täglichen Flotten-Kontrollen schrumpften von einer Reihe von Terminal-Befehlen pro App auf einen Blick auf eine Seite. Der privilegierte Docker-Zugriff bleibt in einem einzigen isolierten Sidecar versiegelt, statt über die beobachteten Apps verteilt zu sein, und routinemäßige Neustarts geschehen nun vom Dashboard aus, mit einem Protokoll darüber, wer was getan hat.

Ehrliche Grenzen

Dies ist ein internes Betriebswerkzeug, kein Produkt. Es läuft im lokalen Labor, um eine selbst gehostete Flotte zu beobachten, und wurde allein für einen Betreiber gebaut. Der ehrliche Kompromiss: Der Python-Sidecar hält privilegierten Zugriff auf den Docker-Socket. Selbst nur lesend eingebunden, hinter einem geteilten Geheimnis in einem isolierten Netzwerk und ohne externen Port, ist alles, was den Socket erreicht, praktisch root-nah auf dem Host. Dieses Risiko wird bewusst akzeptiert und eingedämmt, indem es aus der nutzerseitigen App herausgehalten wird, beseitigt ist es nicht.