Eine Sandbox für Demos, die du wegwirfst

Jede Demo, die ich jemandem zeigen muss, läuft auf genau einer Maschine, und nichts davon darf auch nur in die Nähe der wichtigen Hosts kommen. Diese Kiste betreibt eine kleine Platform-as-a-Service neben einem Reverse Proxy, und jede Demo ist ein Compose-Projekt mit eigenem Hostnamen, eigener Datenbank, wo nötig, und eigener Lebensdauer.

Das Layout ist bewusst langweilig: Anwendungscode in einem Verzeichnisbaum, Compose-Dateien in einem anderen. Eine Demo ist ein Verzeichnis. Eine Demo zu löschen heißt, ein Verzeichnis zu löschen. Diese Umkehrbarkeit ist der ganze Sinn davon, eine Sandbox zu haben und nicht „ein Ersatzordner auf dem guten Server“.

Drei Dinge, die sich lohnen zu klauen

Ein permanent laufender Canary. Es gibt einen trivialen Hello-World-Service auf demselben Proxy und im selben Netzwerk wie jede Demo. Wenn eine Demo nicht mehr antwortet, ist die erste Frage, ob die Demo kaputt ist oder das Routing, und der Canary beantwortet das mit einer einzigen Anfrage. Er kostet nichts und hat mich mindestens zweimal davor bewahrt, eine eigentlich funktionierende Anwendung zu debuggen.

Observability standardmäßig dran, nicht pro Projekt. Container-Metriken, ein Log-Shipper und ein leichter Agent laufen direkt auf der Kiste, sodass eine Demo Monitoring quasi vererbt. Alles, was du bei jedem neuen Projekt extra hinzufügen musst, fehlt dir irgendwann genau bei dem Projekt, bei dem du es am dringendsten gebraucht hättest.

Demos sind stateful genug, um ehrlich zu sein. Jede bekommt eine echte Datenbank und eine echte Queue, wenn das Design es verlangt, statt eines gemockten Backends. Eine Demo, die nicht auf die Weise scheitern kann, wie das echte System scheitert, ist eine Präsentationsfolie, keine Demo.

Der Bug: Vier laufende Services als vermisst gemeldet

Mein Homelab führt einen Beziehungsgraphen, der von Collectors gebaut wird, die beobachten, was tatsächlich läuft. Es meldete vier dieser Demos als dokumentiert, aber nicht beobachtet — die Flagge, die für einen Service gesetzt wird, der auf dem Papier existiert, in Wirklichkeit aber verschwunden ist.

Alle vier liefen. Ich habe nachgeprüft.

Die Ursache ist ein Namensproblem mit drei Achsen:

• Mein Inventory benennt den logischen Service
• Der Collector beobachtet den Containernamen
• Das Uptime-Monitoring nutzt einen Anzeigenamen

Nichts stimmte die drei ab, sodass ein Service, dessen Containername vom Inventory-Namen abwich, im Graphen aussah wie ein Service, den noch nie jemand gesehen hat. Die Lösung war eine Alias-Map plus die bewusste Entscheidung, Sidecars nicht zusammenzuführen — die Datenbank- und Worker-Container bleiben eigenständig, statt in den Service, den sie unterstützen, aufzugehen, weil das Zusammenfassen einen toten Worker hinter einem gesunden Web-Container verstecken würde.

Der Teil, den ich nicht gefixt habe

Die Alias-Map ist flach: Service-Name zu Container-Namen, ohne Bezug auf den Host. Und zwei meiner Maschinen laufen mit Containern mit identischen Namen — die Sandbox-Demo und der echte GPU-Stack dahinter.

Das ist aktuell harmlos, weil nur einer dieser Hosts einen Container-Collector hat. Wenn der andere irgendwann auch einen bekommt, würde die Alias-Map stillschweigend den Produktions-Stack in die Demo-Identität aufnehmen.

Ich habe das im Commit dokumentiert, statt es zu fixen. Nicht, weil es zu schwer wäre — host-spezifische Aliase sind die naheliegende Lösung — sondern weil ein latentes Problem, das dokumentiert ist, ein bekannter Risikofaktor mit klarem Auslöser ist, während ein latentes Problem, das unter Zeitdruck ohne Test gefixt wurde, einfach ein anderer Bug ist, dem du noch nicht begegnet bist. Der Auslöser ist aufgeschrieben. Wenn dieser Host einen Collector bekommt, wartet die Notiz.

„Nicht beobachtet“ ist eine Aussage über den Beobachter. Es hat vier gesunde Services gebraucht, die als vermisst gemeldet wurden, bis mir das klar wurde.