Ein Sicherheitsupdate für 40 Server, eine geänderte Firewall-Regel auf allen Webservern, ein neuer Benutzer für das Monitoring: Solche Aufgaben erledigen viele IT-Abteilungen noch per Hand, Server für Server. Das kostet Zeit und erzeugt schleichende Unterschiede. Nach einem Jahr gleicht kaum ein Server dem anderen, und niemand weiß mehr genau, warum.

Ansible setzt hier an. Statt Befehle von Hand einzutippen, beschreiben Administratoren in einer Textdatei, wie ein System aussehen soll. Ansible sorgt dann dafür, dass jeder Server diesem Zustand entspricht, beliebig oft und nachvollziehbar. Das Werkzeug ist Open Source, vergleichsweise leicht zu lernen und gehört heute zum Standardwerkzeug vieler DevOps- und Betriebsteams.

Was Ansible ist und woher es kommt

Ansible ist ein Werkzeug für Konfigurationsmanagement und Automatisierung. Konfigurationsmanagement heißt: Software, Einstellungen, Benutzer und Dienste auf vielen Rechnern einheitlich und reproduzierbar verwalten. Michael DeHaan veröffentlichte Ansible 2012. Das gleichnamige Unternehmen dahinter übernahm Red Hat 2015, das Projekt blieb aber Open Source.

Heute gibt es zwei Ebenen. Das kostenlose Kommandozeilenwerkzeug besteht aus ansible-core, dem Kern mit den wichtigsten Modulen, und dem Paket ansible, das zusätzlich eine große Auswahl an Erweiterungen der Community mitbringt. Darüber bietet Red Hat die kommerzielle Ansible Automation Platform an, mit Weboberfläche, Rechteverwaltung, Protokollierung und Support. Eine ihrer Open-Source-Grundlagen ist AWX.

Ansible gehört zur Familie der Infrastructure-as-Code-Werkzeuge: Infrastruktur und Konfiguration werden als Code beschrieben, in Git versioniert und wie Software geprüft. Einen Überblick über das Prinzip gibt unsere Themenseite zu Infrastructure as Code.

So arbeitet Ansible: Control Node, Inventar und Module

Das Grundprinzip ist schlicht, und genau das macht Ansible beliebt:

• Control Node: Der Rechner, auf dem Ansible läuft, etwa der Laptop eines Administrators oder ein Server in der CI/CD-Pipeline. Er muss ein Unix-artiges System sein, etwa Linux, macOS oder BSD. Unter Windows funktioniert das nur über das Windows-Subsystem für Linux (WSL).
• Managed Nodes: Die Zielsysteme, die Ansible verwaltet. Auf ihnen muss kein Ansible-Programm installiert sein. Es genügen ein SSH-Zugang und Python, was bei üblichen Linux-Distributionen vorhanden ist. Ansible nennt das „agentenlos“.
• Inventar: Eine Datei, die festlegt, welche Server es gibt und wie sie gruppiert sind, etwa „webserver“ und „datenbanken“. Für Cloud-Umgebungen lässt sich das Inventar auch dynamisch aus der Cloud-API erzeugen.
• Module: Kleine Programme für eine Aufgabe, etwa ein Paket installieren, eine Datei kopieren oder einen Dienst starten. Ansible überträgt sie per SSH, führt sie aus und räumt danach wieder auf.

Windows-Server lassen sich ebenfalls verwalten, dort über WinRM oder inzwischen auch per SSH, mit eigenen Modulen für Windows.

Playbooks, Rollen und Collections

Was zu tun ist, steht in Playbooks: YAML-Dateien, die festlegen, welche Aufgaben (Tasks) auf welchen Servergruppen laufen. Wiederverwendbare Bausteine fasst man in Rollen zusammen, etwa eine Rolle „nginx“ mit Aufgaben, Vorlagen und Standardwerten. Module und Rollen werden seit einigen Jahren in Collections verteilt, Paketen, die man über Ansible Galaxy, das öffentliche Verzeichnis der Community, oder aus eigenen Quellen installiert.

Idempotenz: das wichtigste Prinzip

Die meisten Ansible-Module sind idempotent. Das bedeutet: Sie ändern nur dann etwas, wenn der Ist-Zustand vom Soll-Zustand abweicht. Steht im Playbook „nginx ist installiert“, installiert Ansible das Paket beim ersten Lauf und meldet bei jedem weiteren Lauf nur „ok“. Ein Playbook lässt sich deshalb gefahrlos wiederholen, und es zeigt zuverlässig an, welche Server tatsächlich verändert wurden.

Diese Eigenschaft gilt allerdings nicht automatisch für alles. Wer mit den Modulen command oder shell beliebige Befehle ausführt, muss selbst dafür sorgen, dass ein zweiter Lauf keinen Schaden anrichtet.

Ein Praxisbeispiel: Webserver einheitlich einrichten

Angenommen, ein Unternehmen betreibt zwei Ubuntu-Server für sein Intranet. Beide sollen nginx mit derselben Konfiguration nutzen. Zuerst beschreibt das Inventar die Server:

# inventory.yml
all:
  children:
    webserver:
      hosts:
        web1.example.com:
        web2.example.com:
      vars:
        ansible_user: deploy

Das Playbook legt fest, was auf diesen Servern gelten soll:

# webserver.yml
- name: Webserver einrichten
  hosts: webserver
  become: true
  vars:
    site_name: intranet

  tasks:
    - name: nginx installieren
      ansible.builtin.apt:
        name: nginx
        state: present
        update_cache: true

    - name: Konfiguration aus Vorlage schreiben
      ansible.builtin.template:
        src: templates/site.conf.j2
        dest: '/etc/nginx/sites-available/{{ site_name }}.conf'
        mode: '0644'
      notify: nginx neu laden

    - name: Seite aktivieren
      ansible.builtin.file:
        src: '/etc/nginx/sites-available/{{ site_name }}.conf'
        dest: '/etc/nginx/sites-enabled/{{ site_name }}.conf'
        state: link
      notify: nginx neu laden

    - name: nginx starten und beim Booten aktivieren
      ansible.builtin.service:
        name: nginx
        state: started
        enabled: true

  handlers:
    - name: nginx neu laden
      ansible.builtin.service:
        name: nginx
        state: reloaded

Einige Details sind typisch für gutes Ansible. Die Module werden mit vollem Namen angesprochen (ansible.builtin.apt statt nur apt), so ist eindeutig, aus welcher Collection sie stammen. become: true führt die Aufgaben mit Administratorrechten aus. Der Handler am Ende läuft nur, wenn sich die Konfiguration tatsächlich geändert hat. nginx wird also nicht bei jedem Lauf unnötig neu geladen. Die Vorlage site.conf.j2 ist eine Jinja2-Datei, in die Ansible Variablen wie den Seitennamen einsetzt.

Ausgeführt wird das Playbook auf dem Control Node:

# Probelauf: zeigt, was sich ändern würde, ohne etwas zu ändern
ansible-playbook -i inventory.yml webserver.yml --check --diff

# Echter Lauf
ansible-playbook -i inventory.yml webserver.yml

Der Probelauf mit --check --diff ist eine der nützlichsten Funktionen im Alltag. Er zeigt vor einer Änderung an der Produktion genau, welche Dateien und Dienste betroffen wären.

Passwörter und Schlüssel schützen

Zugangsdaten gehören nicht im Klartext ins Repository. Ansible bringt dafür Ansible Vault mit, das Variablendateien verschlüsselt. Mit ansible-vault encrypt group_vars/webserver/vault.yml wird eine Datei verschlüsselt, beim Ausführen fragt Ansible das Passwort ab oder liest es aus einer geschützten Quelle. Größere Umgebungen binden stattdessen oft einen zentralen Secret-Manager wie HashiCorp Vault oder den Dienst ihres Cloud-Anbieters an.

Ansible, Terraform, Puppet: wer macht was

Ansible wird oft mit anderen Werkzeugen verglichen, die auf den ersten Blick dasselbe tun. Die Abgrenzung hilft bei der Auswahl:

Die wichtigste Abgrenzung ist die zu Terraform. Terraform merkt sich in einer State-Datei, welche Cloud-Ressourcen es angelegt hat, und kann sie deshalb sauber ändern oder löschen. Ansible hat kein solches Gedächtnis. Es kann zwar über Cloud-Module ebenfalls virtuelle Maschinen anlegen, ist darin aber weniger stark. In der Praxis ergänzen sich beide: Terraform baut die Infrastruktur, Ansible richtet darauf Betriebssystem und Anwendungen ein. Wie Terraform arbeitet, erklärt unser Beitrag Terraform erklärt: Cloud-Infrastruktur als Code verwalten.

Wer ausschließlich Container auf Kubernetes betreibt, braucht Ansible für die Anwendungen selbst meist kaum noch. Für die Server darunter, für Netzwerkgeräte oder klassische virtuelle Maschinen bleibt es aber gefragt. Gerade in gemischten Umgebungen mit Linux, Windows und Netzwerktechnik spielt Ansible seine Stärke aus.

Bewährte Praktiken und typische Stolpersteine

Ansible ist schnell gelernt, aber auch schnell unübersichtlich. Einige Regeln helfen:

1. Alles in Git. Playbooks, Inventare und Rollen gehören in ein Repository, Änderungen laufen über Reviews.
2. Rollen statt Riesen-Playbooks. Wiederkehrende Aufgaben als Rollen kapseln und mit Variablen anpassen.
3. Versionen festhalten. Die Version von ansible-core und der verwendeten Collections fixieren, etwa in requirements.txt für pip und requirements.yml für Collections, damit derselbe Code morgen noch gleich läuft.
4. Prüfen vor dem Ausrollen. Mit ansible-lint stilistische und inhaltliche Fehler finden, mit Molecule Rollen in Testumgebungen ausprobieren, mit --check vor Produktivläufen vergleichen.
5. shell und command sparsam einsetzen. Für fast jede Aufgabe gibt es ein passendes Modul, das idempotent arbeitet.
6. Keine Handarbeit nebenher. Wer Server zusätzlich von Hand ändert, untergräbt den Nutzen. Regelmäßige Läufe zeigen solche Abweichungen.

Ein häufiger Stolperstein ist die Geschwindigkeit. Bei Hunderten Servern dauert ein Lauf über SSH spürbar, weil Ansible standardmäßig nur fünf Server gleichzeitig bearbeitet und jeden Task erst auf allen Servern abschließt, bevor der nächste beginnt. Parallelität (forks), SSH-Pipelining und eine sinnvolle Aufteilung der Playbooks schaffen Abhilfe.

Was das für Ihr Team bedeutet

Für die meisten Unternehmen mit eigenen Servern lohnt sich Ansible schon ab einer Handvoll Systemen. Der Einstieg ist niedrig: keine Agenten, keine zentrale Infrastruktur, YAML statt einer eigenen Programmiersprache. Ein erstes Playbook für eine wiederkehrende Aufgabe, etwa das Einspielen von Updates oder das Anlegen von Benutzern, ist in wenigen Stunden geschrieben. Der größere Nutzen entsteht langfristig: Die Konfiguration ist dokumentiert, neue Server sind in Minuten auf dem Stand der alten, und neue Teammitglieder lesen im Playbook nach, wie ein System eingerichtet ist. Diesen Aspekt beleuchtet unser Infothek-Beitrag zu Ansible, Dokumentation und Onboarding.

Überschätzt wird mitunter, wie weit Ansible allein trägt. Für den Lebenszyklus von Cloud-Ressourcen ist Terraform oder OpenTofu meist die bessere Wahl, für Container-Plattformen sind es Kubernetes-eigene Werkzeuge. Unterschätzt wird dagegen der Aufwand, gewachsene Playbooks sauber zu halten. Ohne Konventionen, Tests und Reviews entsteht dasselbe Durcheinander wie vorher, nur in YAML.

Unsere Empfehlung: Beginnen Sie mit einer klar umrissenen, häufigen Aufgabe, legen Sie von Anfang an Struktur und Prüfschritte fest und bauen Sie den Umfang dann schrittweise aus. Schulungen, Coaching und Unterstützung bei Einführung und Betrieb finden Sie auf unserer Themenseite Automatisierte IT-Prozesse mit Ansible.

Häufige Fragen zu Ansible

Ist Ansible nur für große Unternehmen geeignet?

Nein. Gerade kleine Teams mit wenigen Servern profitieren, weil Ansible keine eigene Infrastruktur braucht. Ein Laptop mit Ansible und SSH-Zugang zu den Servern genügt. Die kommerzielle Automation Platform lohnt sich eher für größere Organisationen mit vielen Teams, Freigabeprozessen und Audit-Anforderungen.

Braucht man Programmierkenntnisse?

Für den Einstieg nicht. Playbooks sind in YAML geschrieben und gut lesbar. Hilfreich sind solide Linux-Kenntnisse, denn Ansible automatisiert nur, was man auch von Hand könnte. Wer eigene Module oder Plugins entwickeln will, braucht Python.

Funktioniert Ansible auch mit Windows-Servern?

Ja. Windows-Systeme werden über WinRM oder SSH angesprochen und mit eigenen Modulen aus der Collection ansible.windows verwaltet. Der Control Node selbst muss aber unter einem Unix-artigen System wie Linux oder macOS laufen, unter Windows über WSL.

Wie installiert man Ansible?

Die Dokumentation beschreibt die Installation als Python-Paket mit pip oder, wo das nicht möglich ist, mit pipx install --include-deps ansible. Viele Linux-Distributionen bieten zudem eigene Pakete an, die allerdings oft eine ältere Version enthalten. In Pipelines bewähren sich Container-Images mit festgelegter Version.