Ansible · Infrastructure as Code · Automatisierung · DevOps

Stell dir vor, zwei Server wurden nach derselben Dokumentation aufgesetzt – von denselben Leuten, zur selben Zeit. Sechs Monate später verhalten sie sich unterschiedlich. Das ist kein Fehler. Das ist der Normalzustand.

Klassische Systemadministration hat ein fundamentales Problem, das sich meist erst dann zeigt, wenn es zu spät ist: Es ist praktisch unmöglich, zwei Server dauerhaft identisch zu halten. Jeder Handgriff hinterlässt Spuren. Ein Paket hier, eine Konfigurationszeile dort, ein Hotfix „nur schnell” eingespielt – und schon entfernen sich Systeme voneinander, still und unbemerkt.

Das Problem hat einen Namen: Configuration Drift

In der Praxis wachsen IT-Infrastrukturen selten nach Plan. Server entstehen durch Kopieren bestehender Systeme oder anhand von Checklisten – was anfangs gut funktioniert. Doch je größer die Umgebung, desto größer die Abweichungen.

Typische Symptome von Configuration Drift

Ein Dienst startet nur auf Server A korrekt
Ein Zertifikat fehlt auf Server B
Eine Firewall-Regel wurde nur lokal angepasst
Library-Versionen weichen voneinander ab
Ein Kernel-Parameter wurde nie dokumentiert
Ein Skript fehlt auf einem der Server

Besonders kritisch wird das in Cluster-Umgebungen, bei Hochverfügbarkeit oder unter Compliance-Anforderungen. Im Ernstfall zeigt sich dann: die Systeme sind eben doch nicht identisch.

Ansible: Nicht konfigurieren, sondern definieren

Ansible löst dieses Problem an der Wurzel – mit einer simplen, aber wirkungsvollen Idee:

Klassisch: Menschen konfigurieren Server manuell, nach bestem Wissen und Gewissen.

Mit Ansible: Der gewünschte Zustand wird definiert – und Ansible stellt ihn automatisiert und reproduzierbar her.

In einem Ansible-Playbook legt man fest: welche Pakete installiert sein müssen, welche Dienste laufen, welche Konfigurationen gelten, welche Nutzer existieren, welche Firewall-Regeln aktiv sind. Und Ansible sorgt dafür, dass exakt dieser Zustand hergestellt wird – immer wieder, auf jedem Server, identisch.

Das folgende Beispiel installiert den Web Server nginx und prüft ob er gestartet ist:

# Beispiel: Ein einfaches Ansible-Playbook
- hosts: webserver
  tasks:
    - name: nginx installieren
      apt:
        name: nginx
        state: present
    - name: nginx starten & aktivieren
      service:
        name: nginx
        state: started
        enabled: true

Diesen Vorgang nennem man Software Defined Infrastructure

ertrauen statt Hoffnung

Der eigentliche Vorteil von Ansible ist nicht Geschwindigkeit – obwohl die Zeitersparnis erheblich ist. Es geht um etwas Tieferes: um Vertrauen.

Vorher

„Ich glaube, der Server ist richtig konfiguriert…”

Mit Ansible

„Der Server entspricht exakt dem definierten Zustand.”

Dieser Unterschied verändert die Arbeitsweise grundlegend. Anstatt auf Zuruf zu reagieren und im Dunkeln zu tappen, arbeitet man mit Systemen, auf die man sich verlassen kann.

Infrastructure as Code – Infrastruktur wird zur Software

Das übergeordnete Prinzip dahinter heißt Infrastructure as Code (IaC): Die gesamte Infrastruktur wird wie Software behandelt – versioniert, getestet, dokumentiert und automatisiert ausgerollt. Die Konfiguration lebt in Git-Repositories, nicht in den Köpfen einzelner Administratoren.

✓ Versioniert
✓ Dokumentiert
✓ Reproduzierbar
✓ Testbar
✓ Skalierbar

In modernen Umgebungen mit hunderten virtuellen Maschinen, Containern, Load Balancern und Cloud-Diensten ist manuelle Verwaltung kaum noch beherrschbar. Je komplexer die Infrastruktur, desto wichtiger wird Automatisierung – nicht als Komfortfunktion, sondern als Grundvoraussetzung für stabilen Betrieb.

„Früher hat jeder Server seine eigene Geschichte gehabt. Heute definiert der Code, wie Infrastruktur aussieht.”

Fazit

Ansible ist mehr als ein Automatisierungstool. Es löst eines der grundlegendsten Probleme der IT: dass manuell konfigurierte Systeme nie vollständig verlässlich sind. Mit Infrastructure as Code wird Infrastruktur reproduzierbar, konsistent, nachvollziehbar – und kontrollierbar. Gerade in Hochverfügbarkeits- und Cluster-Umgebungen ist das heute keine Kür mehr, sondern Pflicht.

4future.digital

Dieser Artikel entstand bei 4future.digital – einem österreichischen Full-Service Cloud Provider mit eigenen Rechenzentren in Europa. Wir bieten alles, was moderne IT braucht: von VPS, Containern und Managed Services über WordPress-Hosting und Domains bis hin zu kollaborativen Arbeitsplatz-Lösungen für Teams und Privatpersonen. Als europäische Alternative ist uns eines besonders wichtig: Deine Daten gehören dir – wir verkaufen sie nicht, wir verwalten sie. Für unsere Community und für Klein- und Mittelunternehmen, die digitale Unabhängigkeit ernst nehmen.

Interessiert?

Wir freuen uns über Kommentare und Fragen im Forum

Über den Autor
Artikel

Werner Illsinger

Werner Illsinger ist systemischer Coach, Unternehmensberater sowie Lektor an der FH-Kärnten. Sein Herzensanliegen ist es, dass Arbeit Spaß macht.

Warum oft kein Server dem anderen gleicht – und wie Ansible das ändert.