Betrieb & Monitoring
Ansible
Ansible ist ein quelloffenes Automatisierungswerkzeug für Konfiguration, Provisionierung und Orchestrierung, agentlos über SSH und idempotent in YAML beschrieben.
- Agentlos über SSH (Push-Modell)
- Idempotente YAML-Playbooks
- Module, Roles, Collections
- Ansible Vault für Secrets
- GPLv3 (ansible-core)
Ansible ist ein quelloffenes Automatisierungswerkzeug für Konfigurationsmanagement, Provisionierung, Deployment und Orchestrierung. Sein Markenzeichen ist die Agentlosigkeit: Es benötigt keine Software auf den Zielsystemen, sondern verbindet sich per SSH (bzw. WinRM für Windows), überträgt den Modul-Code und führt ihn aus. Beschrieben wird der gewünschte Zustand deklarativ in YAML, und die eingebauten Module sind idempotent: Mehrfaches Ausführen ändert nichts mehr, wenn der Zustand bereits stimmt.
Dieser Artikel erklärt das agentlose Push-Modell und die Idempotenz, die Bausteine Playbook, Task, Module, Role und Inventory, Variablen und Facts, Ansible Vault für Secrets, den Unterschied zwischen ansible-core und Collections, die Grenzen der Idempotenz bei command/shell, Ausführungsstrategien für Rolling Updates sowie die Abgrenzung zu Terraform/OpenTofu. Eine zentrale Steuerung bietet AWX.
1. Agentlos und idempotent
Ansible läuft auf einem Control Node und verbindet sich zu den Managed Nodes über SSH; auf den Zielen ist nur ein SSH-Zugang und Python nötig, kein dauerhafter Agent und kein offener Inbound-Port. Das ist das Push-Modell. Die Idempotenz der eingebauten Module sorgt dafür, dass ein Playbook den Soll-Zustand herstellt, statt blind Befehle auszuführen: Existiert das Paket schon, wird nichts geändert. Genau das macht wiederholte Läufe sicher.
2. Bausteine: Playbook, Task, Module, Role
Die Struktur ist überschaubar: Ein Playbook (YAML) enthält Plays, die eine Hostgruppe einer Reihe von Tasks zuordnen. Jeder Task ruft ein Module auf (etwa ansible.builtin.package). Roles bündeln Tasks, Templates, Variablen und Handler in einer standardisierten, wiederverwendbaren Struktur. Das Inventory listet die Ziele (statisch oder dynamisch aus Cloud-APIs). Handler laufen nur, wenn ein Task eine Änderung meldet (typisch: Dienst-Neustart nach Konfigurationsänderung).
Playbook: Webserver installieren und Dienst sicherstellen
- hosts: web
become: true
tasks:
- name: nginx installieren
ansible.builtin.package:
name: nginx
state: present
- name: nginx aktiv und gestartet
ansible.builtin.service:
name: nginx
state: started
enabled: true3. Variablen, Facts und Templates
Variablen lassen sich an vielen Stellen definieren (Inventory, Rollen, Dateien, Kommandozeile) mit klarer Vorrangregel. Über gather_facts sammelt Ansible automatisch Facts (Betriebssystem, IP-Adressen, Hardware) als Variablen vom Zielsystem. Jinja2-Templates rendern Konfigurationsdateien mit Variablen, Schleifen und Bedingungen; das Ergebnis wird auf das Ziel übertragen.
4. Secrets mit Ansible Vault
Ansible Vault verschlüsselt sensible Daten (Passwörter, API-Keys, Zertifikate) mit AES-256 direkt in YAML-Dateien oder als einzelne Variablen. Verschlüsselte Dateien können bedenkenlos in Git eingecheckt werden; das Vault-Passwort wird getrennt verwaltet (interaktiv, Passwortdatei oder über einen Secret-Manager in der CI). Bewährt ist die Trennung in unverschlüsselte Variablennamen und eine verschlüsselte Datei mit den geheimen Werten.
5. Idempotenz-Grenzen und Strategien
Nicht alles ist automatisch idempotent: Die Module command und shell führen ihren Befehl immer aus und melden stets „changed“. Gegenmittel sind die Parameter creates/removes (überspringen, wenn eine Datei existiert oder fehlt) und changed_when (Status manuell steuern). Für gestaffelte Rollouts sorgt serial (Hosts in Batches), gegen Engpässe bei vielen Hosts helfen mehr forks und SSH-Multiplexing. Als Pull-Variante gibt es ansible-pull, bei der jeder Host sich selbst aus Git aktualisiert.
Wer command und shell wie eine Allzweckwaffe einsetzt, verschenkt den Kernvorteil von Ansible. Idempotenz entsteht nicht von selbst, sondern durch die konsequente Nutzung dedizierter Module und bewusster Steuerung der Ausnahmen.
6. Abgrenzung zu Terraform und Einordnung
Ansible und Terraform/OpenTofu sind komplementär: Terraform provisioniert und verwaltet Infrastruktur deklarativ mit einem persistenten State (VMs, Netze, Cloud-Ressourcen), Ansible konfiguriert bestehende Systeme und führt Aufgaben darauf aus. Eine verbreitete Kombination ist „Terraform baut, Ansible konfiguriert“. Ansible kennt kein State-File wie Terraform; den Soll-Ist-Abgleich erledigt es über die Idempotenz der Module. Für zentrale Steuerung, Rechte und Auditierung kommt AWX obendrauf.
7. Stärken und Grenzen
| Stärken | Grenzen |
|---|---|
| Agentlos: minimaler Footprint, kein Agent-Lifecycle | Kein State-File: kein automatisches Ressourcen-Tracking wie Terraform |
| YAML-Playbooks gut lesbar und nachvollziehbar | command/shell nicht automatisch idempotent |
| Riesiges Modul- und Collection-Ökosystem, idempotent | SSH-Skalierung ist der Engpass bei sehr vielen Hosts |
| Ansible Vault: verschlüsselte Secrets Git-tauglich | Python auf den Zielen erforderlich |
| Push und optional Pull (ansible-pull) möglich | Kein Convergence-Loop wie bei Puppet/Chef |
Häufige Fragen zu Ansible
Nein. Ansible arbeitet agentlos: Es verbindet sich per SSH (bzw. WinRM bei Windows), überträgt den Modul-Code und führt ihn aus. Voraussetzung auf Linux-Zielen ist lediglich ein SSH-Zugang und Python. Es muss kein dauerhafter Dienst installiert oder ein Inbound-Port geöffnet werden.
Beides, je nach Aufgabe. Terraform/OpenTofu ist für das Provisionieren von Infrastruktur mit State gedacht, Ansible für das Konfigurieren bestehender Systeme. Sie konkurrieren nicht, sondern ergänzen sich: oft baut Terraform die Infrastruktur und Ansible konfiguriert sie anschließend.
Auch der Autor ist nur ein Mensch, dem Fehler unterlaufen können. Wenn in diesem Beitrag etwas nicht stimmt oder unklar ist, freuen wir uns über einen kurzen Hinweis über das Kontaktformular unten, wir prüfen und korrigieren das.
Der nächste Schritt
Ansible im eigenen Haus richtig einsetzen?
Wir klären, ob und wie der Baustein zu Ihrer Infrastruktur passt, und sagen offen, wann sich der Aufwand lohnt und wann nicht.