Umzug auf optimus: die eigene Härtung blockte den eigenen Exporter

Kurz zur Einordnung: Das Control Center ist mein selbst gebautes Mini-NOC — Prometheus sammelt, eine eigene Web-App zeigt. Bis heute lief es nur als Dev-Stack auf dem Mac: Hot-Reload, Source-Mounts, Frontend-Dev-Server. Ein NOC, das mit dem Laptop einschläft, ist keins. Also in den Dauerbetrieb auf optimus, den Homeserver — nur im LAN.

Der Deploy-Weg: Das Repo ist privat und hat keinen Cloud-Remote. Der einfachste saubere Weg war ein Git-Bare-Repo direkt auf optimus, im Mac-Checkout als Remote eingetragen; daneben eine Arbeitskopie, aus der Compose baut. Updates sind seither git push, git pull, up -d --build. Dazu ein eigenes docker-compose.prod.yml: Restart-Policies, keine Source-Mounts, Pflicht-Secrets statt Dev-Defaults, das Frontend als Multi-Stage-Image mit Next.js output: standalone. Kleine Falle dabei: NEXT_PUBLIC_*-Variablen werden zur Build-Zeit ins Image gebacken — ändert sich die API-URL, hilft kein Neustart, nur ein neues Image.

Das Statusbild war sofort ehrlich. Alle 7 Container up, und 15 Services zeigten echte cAdvisor-Metriken — auf dem Mac unmöglich, weil dort die rund 20 optimus-Container gar nicht laufen. Dafür stand optimus selbst auf Warnung: Prometheus erreichte den node_exporter auf dem Host nicht.

Die Suche: Scrape-Timeouts auf Port 9100. Aus jedem Bridge-Container. Genauso auf Port 22. Ein anderer Exporter, den Docker per veröffentlichtem Port bereitstellt, ging dagegen problemlos. Das war der Hinweis: Published Ports laufen über DNAT und die FORWARD-Kette; Verkehr von einem Docker-Bridge-Netz direkt auf den Host landet in INPUT. Und dort stand meine eigene Regel aus einer früheren Host-Härtung: Policy DROP, nur das LAN erlaubt. Die Bridge-Subnetze fielen durch. Lösung: das Netz des Stacks im Compose auf ein festes Subnetz gepinnt und genau dafür eine INPUT-Regel auf Port 9100 ergänzt. Abends verifiziert: Target up, optimus healthy mit vollen Host-Metriken.

Zweite Falle: Das Subnetz ließ sich nicht im laufenden Betrieb pinnen. Nach up -d mit neuer ipam-Konfiguration hing das Backend in einer DNS-Crashloop, weil es den Postgres-Container nicht mehr auflösen konnte — Compose hatte das benutzte Netz nicht sauber neu angelegt. Erst down und up -d (Volumes bleiben) brachten alle Container healthy.

Gelernt: Bei Container-zu-Host-Timeouts systematisch isolieren — anderer Port, anderer Container, DNAT-Pfad gegen INPUT-Pfad — und die eigenen Härtungsregeln als Verdächtigen Nummer eins behandeln. Und ipam-Änderungen an bestehenden Compose-Netzen brauchen down/up, kein reines up -d.