AnsibleDevOpsAutomatisierung

Ansible: Server-Konfiguration und Deployments automatisieren ohne Agenten

21.05.2026 8 Min. Lesezeit

Wer mehrere Server verwaltet, kennt das Problem: Jede manuelle Änderung schleicht sich als undokumentierter Sonderfall ein, bis niemand mehr genau weiß, warum Server A anders konfiguriert ist als Server B. Ansible schafft hier Abhilfe – als Konfigurationsmanagement- und Automatisierungswerkzeug, das vollständig ohne Installation von Agenten auf den Zielsystemen auskommt.

Was ist Ansible?

Ansible ist ein Open-Source-Automatisierungswerkzeug von Red Hat, das Konfigurationsmanagement, Application Deployment und Task-Automatisierung vereint. Im Gegensatz zu anderen Tools wie Puppet oder Chef benötigt Ansible auf den verwalteten Systemen keine vorinstallierte Agent-Software – es reicht ein SSH-Zugang und Python.

Agentless: Warum das ein Vorteil ist

Das agentless Konzept hat mehrere praktische Vorteile: Kein Agenten-Rollout bei neuen Servern, keine Agenten-Updates, kein dauerhafter Hintergrundprozess, der Ressourcen verbraucht. Ansible verbindet sich per SSH (oder WinRM für Windows), führt die notwendigen Aktionen aus und trennt die Verbindung wieder. Alles, was der Zielserver braucht, ist Python ab Version 3.x.

Kernkonzepte

Inventory

Das Inventory listet alle Server auf, die Ansible verwalten soll. Es kann als einfache INI-Datei oder als YAML vorliegen. Server lassen sich in Gruppen organisieren:

[webserver]
web1.example.com
web2.example.com

[datenbankserver]
db1.example.com

[alle:children]
webserver
datenbankserver

Playbooks

Ein Playbook ist eine YAML-Datei, die beschreibt, was auf welchen Hosts ausgeführt werden soll. Es besteht aus einem oder mehreren Plays, jeder Play aus einer Liste von Tasks.

Tasks und Module

Jeder Task verwendet ein Ansible-Modul, das eine konkrete Aktion kapselt. Die wichtigsten Module:

apt / yum / dnf – Pakete installieren, aktualisieren oder entfernen
copy – Dateien auf den Zielserver kopieren
template – Jinja2-Vorlagen rendern und übertragen
service – Systemdienste starten, stoppen oder neustarten
user – Benutzer anlegen und verwalten

Rollen (Roles)

Komplexere Playbooks werden über Rollen strukturiert. Eine Rolle ist ein standardisiertes Verzeichnislayout mit Tasks, Handlers, Templates, Variablen und Defaults. Fertige Rollen für gängige Anwendungen (nginx, MySQL, Redis …) findet man auf Ansible Galaxy.

Idempotenz

Eines der Kernprinzipien von Ansible ist Idempotenz: Ein Playbook kann beliebig oft ausgeführt werden – wenn der gewünschte Zustand bereits erreicht ist, werden keine Änderungen vorgenommen. Das Modul apt installiert ein Paket also nur, wenn es noch nicht installiert ist, und überspringt den Schritt andernfalls.

Tipp: Mit ansible-playbook playbook.yml --check lässt sich ein Playbook im Dry-Run-Modus ausführen. Ansible zeigt dann an, was geändert würde, ohne tatsächliche Änderungen vorzunehmen – ideal vor dem ersten Einsatz auf Produktivsystemen.

Praxis-Playbook: LEMP-Stack einrichten

Das folgende Playbook installiert Nginx, MySQL und PHP auf einem Ubuntu-Server:

---
- name: LEMP-Stack installieren
  hosts: webserver
  become: true

  vars:
    mysql_root_password: "geheimes_passwort"

  tasks:
    - name: Pakete installieren
      apt:
        name:
          - nginx
          - mysql-server
          - php-fpm
          - php-mysql
        state: present
        update_cache: true

    - name: Nginx-Konfiguration kopieren
      template:
        src: templates/nginx.conf.j2
        dest: /etc/nginx/sites-available/default
      notify: Nginx neustarten

    - name: MySQL starten und aktivieren
      service:
        name: mysql
        state: started
        enabled: true

    - name: Nginx starten und aktivieren
      service:
        name: nginx
        state: started
        enabled: true

  handlers:
    - name: Nginx neustarten
      service:
        name: nginx
        state: restarted

Ausgeführt wird das Playbook mit: ansible-playbook -i inventory.ini lemp.yml

Vergleich: Ansible vs. Puppet vs. Chef vs. Salt

Kriterium	Ansible	Puppet	Chef	Salt
Agentless	Ja (SSH)	Nein (Agent)	Nein (Agent)	Beides möglich
Sprache/Format	YAML	Puppet DSL	Ruby (DSL)	YAML / Jinja2
Lernkurve	Flach	Moderat–Steil	Steil	Moderat
Push vs. Pull	Push	Pull	Pull	Beides
Skalierung	Gut (bis tausende Hosts)	Sehr gut	Sehr gut	Sehr gut
Community	Sehr groß	Groß	Mittel	Mittel

Achtung: Bei sehr großen Umgebungen (zehntausende Server) kann Ansible durch seine SSH-basierte Architektur an Performance-Grenzen stoßen. Für solche Szenarien empfehlen sich Pull-basierte Tools wie Puppet oder Salt mit einem zentralen Master-Server.

Ansible AWX und Automation Platform

Für Teams bietet Red Hat mit AWX eine kostenlose Web-Oberfläche für Ansible, die Zeitplanung, Zugriffskontrollen und Job-Historien bietet. AWX ist das Open-Source-Upstream-Projekt der kommerziellen Red Hat Ansible Automation Platform.

Häufig gestellte Fragen

Brauche ich Python auf allen verwalteten Servern?: Ja, Python wird auf den Zielsystemen benötigt. Moderne Linux-Distributionen haben Python in der Regel vorinstalliert. Für Windows-Hosts wird WinRM statt SSH genutzt.
Was ist der Unterschied zwischen einem Task und einem Handler?: Tasks werden in der angegebenen Reihenfolge ausgeführt. Handler werden dagegen nur ausgeführt, wenn sie durch ein notify in einem Task ausgelöst wurden, und das immer erst am Ende eines Plays – egal wie oft sie ausgelöst wurden.
Wie sichere ich Passwörter in Playbooks ab?: Mit Ansible Vault lassen sich sensible Variablen oder ganze Dateien verschlüsseln. Der Befehl ansible-vault encrypt_string verschlüsselt einzelne Werte, die dann direkt in Playbooks eingebettet werden können.
Kann Ansible auch Windows-Server verwalten?: Ja. Ansible unterstützt Windows über WinRM (Windows Remote Management). Dafür gibt es eine eigene Sammlung von Windows-Modulen (ansible.windows), mit der u. a. Chocolatey-Pakete, IIS und Active-Directory verwaltet werden können.