Wie lässt sich Umgebungsdrift zwischen Staging und Produktion vermeiden? Ein Entwickler hat dafür eine Inter-Mesh-Deployment-Pipeline entworfen, die auf seiner eigenen Infrastruktur läuft.
Der Autor betreibt rund 72 Anwendungen in zwei Umgebungen. Offiziell sieht der Prozess so aus: erst Staging, dann testen, dann Produktion. In der Praxis blieb dieser Weg oft ungenutzt. Es gab keine technische Möglichkeit, die Reihenfolge zu erzwingen. So entwickelten sich die beiden Umgebungen auseinander – ein Fall von Umgebungsdrift.
Du kennst das aus eigenen Projekten: Ohne automatisierte Kontrolle weicht die Konfiguration von Staging und Produktion voneinander ab. Neue Abhängigkeiten werden nur in Produktion ergänzt, Umgebungsvariablen unterscheiden sich, und plötzlich ist Staging kein verlässlicher Testort mehr. Genau dieses Problem wollte der Entwickler lösen.
Das Problem: Umgebungsdrift und fehlende Kontrolle
Umgebungsdrift entsteht, wenn zwei Umgebungen, die identisch sein sollten, durch manuelle Eingriffe oder fehlende Automatisierung voneinander abweichen. Im Fall des Autors war die Theorie klar: Jede Änderung sollte zuerst nach Staging, dann nach sorgfältigem Testen nach Produktion. Aber keine technische Hürde erzwang diesen Ablauf. Entwickler konnten direkt auf Produktion deployen, wenn sie es eilig hatten, oder Konfigurationen lokal ändern, ohne sie zu dokumentieren.
Die Folgen waren vorhersehbar: Staging wurde selten genutzt, veraltete Daten oder fehlerhafte Abhängigkeiten machten Tests unzuverlässig, und niemand wusste mehr, was auf welcher Umgebung lief. Bei so vielen Anwendungen war das ein erhebliches Risiko. Ein Fehler, der nur in Produktion auftrat, konnte teuer werden.
Um das zu beheben, brauchte der Autor eine Möglichkeit, den gewünschten Ablauf technisch zu erzwingen und gleichzeitig vollständige Transparenz über alle Deployments zu erhalten.
Die Idee: Eine NATS-Bridge als Verbindungsstück
Die Lösung bestand darin, einen speziellen Connector zu entwickeln, der als Brücke zwischen den beiden Meshes fungiert. Ein Mesh ist ein Netzwerk aus Diensten, die über gemeinsame Kommunikationsprotokolle verbunden sind. Der Connector nutzt NATS, einen Message-Broker, um Nachrichten zwischen den Umgebungen auszutauschen.
Durch diese NATS-Bridge kann die Produktionsumgebung direkt Anfragen an die Staging-Umgebung senden. Ein Build und Test einer Komponente lässt sich so anstoßen, ohne dass ein Mensch eingreift. Der Autor nutzte diesen Mechanismus zuerst, um neue Anwendungen auszurollen. Denn wenn die Pipeline weiß, wie man eine neue App korrekt installiert, kann sie dieselbe Logik auf bestehende Anwendungen anwenden.
Das Besondere daran ist, dass nicht nur der initiale Deploy automatisiert wird, sondern auch spätere Updates. In der Produktionsoberfläche gibt es eine Schaltfläche „Pull from Staging“. Sie löst einen vollständig überwachten Prozess aus, der die Artefakte von Staging abruft und in Produktion übernimmt. Jeder Schritt wird protokolliert, sodass ein lückenloses Audit möglich ist.
Sicherheit durch Privilegientrennung: das proc-mesh-Konzept
Ein so flexibles Werkzeug bringt Sicherheitsfragen mit sich. Der Autor setzt auf ein abgestuftes Rechtsmodell, den „layered approach to security“. Eine zentrale Rolle spielt eine Komponente namens proc-mesh, die mit minimalen Rechten läuft. Sie hat keinerlei Netzwerkzugriff und kommuniziert nur über einen Unix-Socket.
Alle anderen Komponenten in der Pipeline haben das Flag NoNewPrivileges=yes gesetzt. Das bedeutet, dass sie keine zusätzlichen Rechte erlangen können, selbst wenn sie versuchen, bestimmte Systemaufrufe zu nutzen. Für privilegierte Aktionen, die nötig sind, setzt der Autor doas ein – ein Programm zur kontrollierten Erhöhung von Rechten. proc-mesh ist die einzige Instanz, die solche Aufrufe durchführen darf.
Dieses Sicherheitskonzept hat einen interessanten Effekt: Selbst wenn ein Angreifer es schafft, eine Komponente zu kompromittieren und Rechte zu erlangen, verliert er gleichzeitig die Fähigkeit, über das Netzwerk zu kommunizieren. Denn die Rechteausweitung läuft nur über den Unix-Socket von proc-mesh, der selbst keine Netzwerkverbindung hat. So wird ein potenzieller Schaden begrenzt.
Deployments per API und der Wert von Audit-Logs
Die Pipeline lässt sich nicht nur über die grafische Oberfläche steuern, sondern auch per API oder über das MCP-Protokoll. MCP steht für Model Context Protocol, ein Protokoll, das es KI-Agenten ermöglicht, mit Tools zu interagieren. In diesem Fall können automatisierte Agenten Deployments anstoßen, was die Integration in CI/CD-Workflows erleichtert.
Jeder dieser Deployments erzeugt eine vollständige Audit-Liste. Der Autor zeigt in einem Diagramm, wie die einzelnen Schritte ablaufen: schwarze Pfeile zeigen ausgehende Verbindungen, rote Pfeile den Rückweg. Artefakte werden nicht über Git-Releases übertragen, sondern als Binärdaten direkt über die NATS-Bridge verschickt. Das ist schneller und vermeidet die Abhängigkeit von einer zusätzlichen Release-Verwaltung.
Dank der Audit-Logs lässt sich jederzeit nachvollziehen, welche Version einer Anwendung auf welcher Umgebung läuft und wie der Weg dorthin aussah. Das erhöht das Vertrauen in die Deployments und erleichtert die Fehlersuche, falls etwas schiefgeht.
Bulk-Operationen: Wie sich die Umgebungen wieder angleichen lassen
Nachdem der Autor die Pipeline für neue Anwendungen etabliert hatte, konnte er sie nutzen, um die bestehenden Umgebungen zu synchronisieren. Da die Pipeline weiß, wie eine korrekte Installation aussieht, kann sie jede Anwendung prüfen und bei Bedarf anpassen. Dies geschieht in einem Bulk-Verfahren: Zuerst wird jede App in der Staging-Umgebung aufgesetzt und getestet, dann nach Produktion übernommen.
Der Prozess ist so gestaltet, dass Fehler in Staging abgefangen werden, bevor sie Auswirkungen auf Produktion haben. Das entspricht der ursprünglichen Idee einer sauberen Trennung. Nach und nach bringt er alle 72 Anwendungen auf den gewünschten Zustand und beseitigt die Umgebungsdrift.
Der Aufwand dafür ist überschaubar, weil die Pipeline einen einheitlichen Weg für alle Apps erzwingt. Das zeigt, dass ein gut durchdachtes Deployment-System nicht nur Neubauten beschleunigt, sondern auch Altlasten systematisch abtragen kann.
Die Grenze des Systems: Selbst-Deployment von Mesh-Komponenten
Natürlich gibt es auch blinde Flecken. Der Autor merkt an, dass seine Komponente plug-mesh sich selbst nicht über die neue Pipeline deployen kann. Sie verlässt sich noch auf die alte Gitea-Runner-Integration. Um das zu ändern, hätte er eine isolierte NATS-Bridge zwischen einer neuen Instanz von plug-mesh und der bestehenden Komponente einrichten müssen.
Die Idee war, die neue Komponente in dieser isolierten Umgebung zu testen, bevor sie die alte ersetzt. In der Praxis stellte sich heraus, dass er diese Komponente selten anpasst. Daher hat er die Selbst-Deployment-Funktion nicht weiter verfolgt. Er akzeptiert, dass Staging in manchen Fällen kaputtgehen kann – aber genau dafür ist es da: um Fehler zu entdecken, bevor sie in Produktion gelangen.
Diese pragmatische Entscheidung zeigt, dass nicht jede theoretische Verbesserung sofort umgesetzt werden muss. Oft reicht es, eine saubere Basis zu haben und die wichtigsten Prozesse zu automatisieren.
Diese Inter-Mesh-Deployment-Pipeline zeigt, wie sich Umgebungsdrift vermeiden lässt. Die Kombination aus NATS-Bridge, Privilegientrennung und Logging bietet eine robuste Grundlage. Die Prinzipien lassen sich auch auf kleinere Setups übertragen: den Weg über Staging erzwingen, Rechte trennen, alles protokollieren. So wird Deployen zur Routine statt zum Risiko.
Quelle: blog.zm.is
