Skalieren wie ein Cloud Provider: Wie wir Infrastruktur zuverlässig automatisieren

Über 500 VMs, mehrere Rechenzentren, Kundenumgebungen, mobile Router im öffentlichen Verkehr und ein Engineering-Team von rund 12 Personen. Das funktioniert nicht, wenn jede Konfiguration und jede Änderung manuell gemacht werden muss.

Bei onway setzen wir deshalb stark auf Ansible. Ansible ist ein Open-Source-Tool, das Konfigurationen und Abläufe in lesbaren YAML-Dateien beschreibt und sie automatisiert auf beliebig vielen Systemen ausführt. Nicht weil Automatisierung an sich spannend ist (ist es!), sondern weil sie ein konkretes Betriebsproblem löst: Es verwaltet viele Systeme zuverlässig, nachvollziehbar und konsistent.

Im ersten Beitrag dieser Serie ging es um NetBox als Source of Truth. Dort pflegen wir VMs, IP-Adressen, VLANs, VRFs und weitere Infrastrukturinformationen. NetBox beschreibt, was existiert und wie die Umgebung aussehen soll. Konfiguriert ist damit aber noch nichts. Ansible übernimmt diesen Teil: Es liest die Daten aus NetBox und setzt den gewünschten Zustand auf den Systemen um.

Eine einzelne VM manuell anzupassen ist kein Problem. Bei mehreren hundert VMs –verteilt auf zwei Rechenzentren, mit Routern, Switches, Firewalls und ESXi-Hosts – wird manuelles Vorgehen schnell fehleranfällig, besonders wenn Änderungen sauber dokumentiert sein sollen.

Im Betrieb stellen sich immer wieder dieselben Fragen:

• Welche Systeme sind von einer Änderung betroffen?
• Haben alle VMs die gleiche Basiskonfiguration?
• Wurde ein Security Update überall ausgerollt?
• Gibt es Systeme, die von der gewünschten Konfiguration abweichen?
• Kann unser OPS-Team wiederkehrende Aufgaben sicher selbst ausführen?

Wenn diese Fragen nur manuell gelöst werden können, wird der Betrieb langsam. Noch schwieriger wird es, wenn Dokumentation und effektive Konfiguration auseinanderlaufen. Genau deshalb kombinieren wir NetBox und Ansible.

Eine neue VM wird zuerst in NetBox erfasst: Name, IP-Adresse, Rolle, Umgebung und weitere Details. Ansible arbeitet nicht mit einer statischen Hostliste, sondern direkt gegen diese Source of Truth. Wenn die Daten in NetBox stimmen, kann Ansible damit arbeiten.

Unser Modell ist bewusst simpel:

• NetBox beschreibt den gewünschten Zustand.
• Ansible setzt diesen Zustand auf den Systemen um.
• Rundeck macht die Automatisierung für Engineering und OPS einfach ausführbar.
• E-Mail und Logstash sorgen dafür, dass Änderungen nachvollziehbar bleiben.

Ein typischer Anwendungsfall ist die Provisionierung neuer VMs: Netzwerkkonfiguration setzen, Benutzer einrichten, Monitoring anbinden, Dienste konfigurieren. Mit Ansible werden diese Schritte standardisiert ausgeführt, statt jedes Mal manuell erarbeitet.

Das ist besonders wichtig bei neuen Kundenumgebungen, die schnell aus 20 und mehr Komponenten bestehen, wie Router, Switches, Firewalls, ESXi-Hosts, mehrere VMs. Solche Umgebungen können wir innerhalb weniger Stunden in Betrieb nehmen, mit weniger manuellen Fehlern und einem reproduzierbaren Aufbau.

Auch nach der Provisionierung muss eine VM über längere Zeit korrekt konfiguriert bleiben. Dafür setzen wir Ansible-Rollen ein. Eine Rolle beschreibt, basierend auf der in NetBox gepflegten Funktion der VM, welche Konfiguration ein System braucht.

Ein Auszug aus unseren knapp 50 Rollen:

• `base` für generelle Grundeinstellungen
• `monitoring` für die Einbindung ins Monitoring
• `snmpd` für SNMP-Konfiguration
• `sssd_login` für zentrale Login-Integration
• `sshd` für SSH-Konfiguration
• `mpp` für unsere mpp-Appliance

Eine Basiskonfiguration soll nicht 500-mal manuell umgesetzt werden. Sie soll einmal sauber definiert sein und danach zuverlässig auf allen relevanten Systemen landen. Das macht den Betrieb berechenbarer und reduziert Unterschiede, die beim Troubleshooting Zeit kosten.

Ansible läuft bei uns über die Web-Oberfläche Rundeck. Hier werden die vordefinierten Jobs gestartet, geplant und können protokolliert werden, ohne dass man direkt auf der Kommandozeile arbeiten muss. Das ist wichtig, weil Automatisierung nicht nur für die Personen funktionieren darf, die sie gebaut haben. Unser OPS-Team kann über Rundeck definierte Jobs ausführen, ohne jedes technische Detail zu kennen. Das reduziert Abhängigkeiten von einzelnen Engineers und macht wiederkehrende Aufgaben zugänglicher.

Wenn eine Automatisierung nur auf dem Laptop einer Person funktioniert, hilft sie im Betrieb nur begrenzt.

Wenn eine kritische Vulnerability veröffentlicht wird, muss man schnell wissen, welche Systeme betroffen sind. Danach müssen Updates gezielt ausgerollt und die Änderungen nachvollzogen werden. Bei über 500 VMs möchte man das nicht manuell zusammensuchen.

Ein Beispiel aus unserem Betrieb war eine kritische nginx Vulnerability. Innerhalb einer Stunde konnten wir herausfinden, welche Systeme betroffen waren, und entsprechende Updates ausrollen. Ohne saubere Datenbasis und Automatisierung wäre das deutlich aufwendiger. Man müsste zuerst prüfen, wo nginx installiert ist, welche Systeme produktiv sind und welche Kundenumgebungen betroffen sein könnten. Dabei ist die Gefahr gross, einzelne Systeme zu übersehen.

Mit NetBox und Ansible können wir strukturierter arbeiten:

• betroffene Systeme identifizieren
• Updates gezielt ausrollen
• Änderungen nachvollziehen
• den Zustand der Systeme kontrollieren

Security ist damit nicht nur eine Frage der richtigen Patches. Es geht auch darum, wie schnell und kontrolliert man reagieren kann, wenn es darauf ankommt.

Nicht jede Änderung ist kritisch. Manche sind technisch simpel, aber operativ mühsam. Ohne Automatisierung bleiben solche Aufgaben gerne liegen.

Ein eigenes gutes Beispiel war unser Rebranding von WLAN-Partner zu onway: Die MOTD musste auf allen VMs angepasst werden. Technisch keine grosse Sache, manuell über viele Systeme aber unverhältnismässig aufwendig. Mit Ansible war die Änderung in rund 30 Minuten ausgerollt und hätte manuell wahrscheinlich gar nicht erst stattgefunden.

Systeme verändern sich im Betrieb: Updates, Hotfixes, Tests, manuelle Eingriffe. Im Verlauf der Zeit können VMs voneinander abweichen, ohne dass es auf den ersten Blick auffällt. Das nennt man Config Drift. Man bemerkt dies oft erst beim nächsten Change oder beim Troubleshooting.

Deshalb führen wir Ansible einmal täglich über alle VMs aus. Wenn Änderungen festgestellt werden, erhalten wir eine E-Mail mit den betroffenen Systemen; zusätzlich schreiben wir die Changes nach Logstash. Es dient zur zentralen Log-Aggregation und sammelt Ereignisse aus verschiedenen Quellen und macht sie durchsuchbar. Konsistenz entsteht nicht dadurch, dass man ein System einmal sauber installiert, sondern dadurch, dass der gewünschte Zustand regelmässig überprüft und bei Bedarf wiederhergestellt wird.

Ansible ist bei onway kein Selbstzweck. Wir setzen es ein, weil unsere Infrastruktur zu gross und zu dynamisch ist, um sie dauerhaft manuell zu verwalten. Der Aufbau-Aufwand (Rollen bauen, Daten pflegen, Abläufe testen) zahlt sich im Betrieb aus: weniger repetitive Arbeit, mehr Zeit für Architektur, Troubleshooting und Kundenlösungen.

Für unsere Kunden bedeutet das schnellere Bereitstellung neuer Umgebungen, konsistent konfigurierte Systeme und eine deutlich schnellere Reaktion auf Sicherheitsvorfälle. Automatisierung ist für uns kein Selbstzweck, sondern ein Werkzeug, um Infrastruktur effizient, sicher und zuverlässig zu betreiben.

Betreiben Sie selbst komplexe IT- oder Netzwerkinfrastruktur und möchten wiederkehrende Aufgaben zuverlässiger automatisieren?

onway unterstützt Unternehmen dabei, Source of Truth, Automatisierung und Betriebsprozesse sinnvoll und praxisnah miteinander zu verbinden.