Ansible: Playbooks und Inventory

Bisher haben wir uns auf CI/CD-Pipelines konzentriert – also Software bauen und ausliefern. Aber wer hilft uns, die Server selbst in den richtigen Zustand zu bringen? Genau dafür gibt es Configuration-Management-Tools, und das bekannteste ist Ansible.

Ansible ist Red Hats Open-Source-Tool für Configuration Management und Automatisierung. Anders als Terraform, das Infrastruktur provisioniert, sorgt Ansible dafür dass die Server-Konfiguration stimmt: richtige Pakete installiert, Config-Dateien an Ort und Stelle, Services aktiv. Diese Lektion deckt Playbooks, Inventory, Modules, Roles, Templates ab.

1) Was ist Configuration Management?

Stell dir vor, du musst 50 Webserver einrichten: Linux installieren, Nginx, PHP, MySQL, Firewall-Regeln, User anlegen, Backup-Skripte einrichten. Manuell? Wochen Arbeit, jeder Server leicht anders, Fehler vorprogrammiert. Mit Configuration Management automatisierst du das: ein Script-File beschreibt den Soll-Zustand, das Tool sorgt dafür dass die Server diesen Zustand erreichen.

Wichtige Eigenschaften:

Deklarativ: du beschreibst was sein soll, nicht wie man dahin kommt
Idempotent: das gleiche Skript mehrfach laufen lassen ändert nichts (wenn Soll-Zustand schon erreicht)
Reproduzierbar: gleicher Input erzeugt gleichen Output
Versionierbar: Konfiguration als Code in Git

Konkurrenten: Puppet, Chef, SaltStack. Ansible hat sich durchgesetzt weil es agentless arbeitet – auf den verwalteten Servern braucht's keine Software, nur SSH-Zugriff und Python.

2) Push vs. Pull

Bei Configuration-Management gibt's zwei grundsätzliche Architektur-Ansätze. Ansible folgt dem Push-Modell, was es deutlich einfacher zu starten macht:

Push (Ansible) vs. Pull (Puppet, Chef)

Push-Modell (Ansible)

Der Control Node verbindet sich per SSH zu den verwalteten Servern und führt Tasks aus. Server brauchen nichts vorinstalliert. Einfacher Setup, gut für ad-hoc-Operationen.

Control → SSH → Server

Pull-Modell (Puppet, Chef)

Auf jedem Server läuft ein Agent, der regelmäßig beim Master nach neuer Konfig fragt. Mehr Wartung, aber gut für kontinuierliche Konformität (Server holt sich Updates selbst).

Server → poll → Master

Ansibles Push-Modell ist das Hauptverkaufsargument: kein Agent nötig auf den Zielsystemen. Damit kannst du Ansible auch dort einsetzen wo du keine Software installieren darfst – Compliance-Umgebungen, fremde Infrastruktur. Nachteil: das Pushing geschieht nur wenn du es startest. Mit AWX/Tower kannst du das aber regelmäßig laufen lassen.

3) Die zentralen Konzepte

Ansible hat eine eigene Terminologie die man verstehen muss. Hier die wichtigsten Begriffe als Übersicht – sie werden in den folgenden Abschnitten alle vertieft:

Begriff	Bedeutung
Control Node	Der Rechner auf dem Ansible läuft (dein Laptop oder ein CI-Server)
Managed Nodes	Die Server die du verwaltest (Webserver, DBs, etc.)
Inventory	Datei mit der Liste aller Managed Nodes, gruppiert
Playbook	YAML-Datei mit Tasks die ausgeführt werden sollen
Task	Eine einzelne Aktion: „installiere Nginx", „starte Service"
Module	Plugin das eine Aktion ausführt: `apt`, `service`, `file`, …
Role	Wiederverwendbare Sammlung von Tasks und Variablen für einen Zweck
Vars	Variablen die in Tasks und Templates genutzt werden
Handler	Task der nur läuft wenn andere Tasks „benachrichtigen" (z.B. Service-Restart)

4) Inventory: deine Server-Liste

Das Inventory ist die Datei in der du deine Server organisierst. In INI-Format oder YAML. Du gruppierst Server nach Funktion und kannst pro Gruppe Variablen vergeben:

Beispiel-Inventory

[webservers]

web01.example.comansible_user=ubuntu

web02.example.comansible_user=ubuntu

web03.example.comansible_user=ubuntu

[databases]

db01.example.comrole=primary

db02.example.comrole=replica

[loadbalancers]

lb01.example.com

[production:children]

webservers

databases

loadbalancers

Mit [production:children] erstellst du Meta-Gruppen die andere Gruppen zusammenfassen. So kannst du im Playbook sagen „auf allen production-Servern" und alle drei Untergruppen werden adressiert. Sehr praktisch für komplexe Setups. Inventories können auch dynamisch sein – z.B. via Skript Server aus AWS oder Azure abrufen.

Ein einfaches Inventory als YAML-Variante:

inventory.ymlYAML

1all:
children:
  webservers:
    hosts:
      web01.example.com:
      web02.example.com:
    vars:
      http_port: 80
      app_user: www-data
  databases:
    hosts:
      db01.example.com:

5) Playbook: das Herzstück

Ein Playbook ist die Hauptdatei – beschreibt was getan werden soll. YAML-Datei mit einer Liste von Plays, die jeweils Tasks auf bestimmten Hosts ausführen. Schauen wir uns ein realistisches Playbook für Nginx-Setup an:

setup-webserver.ymlAnsible Playbook

1- name: Setup Webserver
hosts: webservers
become: true          # sudo
vars:
  app_name: "myapp"
6
tasks:
  - name: Update apt cache
    apt:
      update_cache: yes
11
  - name: Install Nginx
    apt:
      name: nginx
      state: present
16
  - name: Copy Nginx config
    template:
      src: nginx.conf.j2
      dest: /etc/nginx/sites-enabled/{{ app_name }}
    notify: restart nginx
22
  - name: Enable Nginx Service
    service:
      name: nginx
      state: started
      enabled: yes
28
handlers:
  - name: restart nginx
    service:
      name: nginx
      state: restarted

Vier Tasks: apt-Cache aktualisieren, Nginx installieren, Konfig kopieren, Service aktivieren. Plus ein Handler der Nginx neu startet – aber nur wenn die Konfig sich geändert hat (durch notify ausgelöst).

Ausgeführt wird das Playbook mit ansible-playbook. So sieht die Ausgabe aus:

Ausführung: ansible-playbook setup-webserver.yml

PLAY [Setup Webserver] ****************** TASK [Gathering Facts] ****************** ok: [web01.example.com] ok: [web02.example.com] TASK [Update apt cache] ***************** changed: [web01.example.com] changed: [web02.example.com] TASK [Install Nginx] ******************** changed: [web01.example.com] ok: [web02.example.com] TASK [Copy Nginx config] **************** changed: [web01.example.com] changed: [web02.example.com] RUNNING HANDLER [restart nginx] ********* changed: [web01.example.com] changed: [web02.example.com] PLAY RECAP ****************************** web01 : ok=5 changed=4 failed=0 web02 : ok=5 changed=3 failed=0

Lies die Ausgabe so: pro Host und Task zeigt Ansible den Status. ok = bereits im Soll-Zustand, nichts getan. changed = etwas verändert. failed = Fehler. Bei web02 war Nginx schon installiert (ok statt changed). Das ist Idempotenz in Aktion – nur was wirklich geändert werden muss, wird angefasst.

6) Idempotenz: das Schlüssel-Konzept

Das wichtigste Konzept in Ansible: Idempotenz. Tasks sind so geschrieben, dass mehrfaches Ausführen dasselbe Ergebnis hat. Erstes Run installiert Nginx – zweites Run sieht „ist schon installiert" und tut nichts:

Idempotenz: 3× das Playbook laufen lassen

Run 1:

Nginx war nicht installiert → wird installiert CHANGED

Run 2:

Nginx schon da, Soll-Zustand erreicht OK (no change)

Run 3:

Immer noch alles wie es sein soll OK (no change)

Ohne Idempotenz wäre Configuration Management chaotisch: jedes Run würde Nginx neu installieren, Configs überschreiben, Services dauernd neu starten. Idempotente Tasks prüfen den Ist-Zustand und tun nichts wenn er dem Soll entspricht. Module wie apt, file, service sind alle idempotent. Achtung: das command- und shell-Modul sind NICHT idempotent! Die laufen jedes Mal. Daher Konditionen mit when:, changed_when:, creates: nutzen.

7) Wichtige Module

Ansible hat über 3.000 Module für alle möglichen Aufgaben. Die wichtigsten die du täglich brauchen wirst:

Die meistgenutzten Ansible-Module

apt / yum / dnf

Pakete installieren (Debian/Ubuntu, RHEL/CentOS)

copy / file

Dateien/Verzeichnisse erstellen, Permissions setzen

template

Jinja2-Template auf Server kopieren mit Variablen-Ersetzung

service / systemd

Services starten, stoppen, aktivieren

user / group

User und Gruppen anlegen, ändern

lineinfile / blockinfile

Einzelne Zeilen oder Blöcke in Dateien bearbeiten

git

Repository klonen oder updaten

command / shell

Shell-Befehl ausführen (NICHT idempotent!)

docker_container

Docker-Container verwalten

Faustregel: lieber ein spezifisches Modul nutzen als command oder shell. apt: name=nginx ist besser als shell: apt install nginx – ersteres ist idempotent, Letzteres läuft jedes Mal. Bei shell/command immer mit Bedingungen arbeiten.

8) Roles: Wiederverwendung im Großen

Bei größeren Setups packst du Tasks in Roles – wiederverwendbare Bausteine mit fester Verzeichnis-Struktur. Eine Role bündelt alles was du für eine bestimmte Funktion brauchst (z.B. einen kompletten Webserver) und kann in verschiedenen Playbooks wiederverwendet werden:

Standard-Verzeichnisstruktur einer Role

roles/ webserver/ tasks/ main.yml ← Haupt-Tasks der Role handlers/ main.yml ← Handler (restart nginx, etc.) templates/ nginx.conf.j2 ← Jinja2-Templates files/ favicon.ico ← Statische Dateien vars/ main.yml ← Variablen (hohe Priorität) defaults/ main.yml ← Default-Werte (niedrige Priorität) meta/ main.yml ← Abhängigkeiten zu anderen Roles

Diese Struktur ist Konvention – Ansible findet automatisch die richtigen Files. Du musst nicht alle Ordner anlegen, nur was du brauchst. Roles werden im Playbook einfach aufgerufen mit roles: [webserver, database] – das spart enorm Code-Duplikation.

Im Playbook nutzt du Roles so:

site.ymlYAML

1- name: Configure all production servers
hosts: webservers
become: true
roles:
  - common          # Basis-Setup für alle Server
  - webserver       # Nginx, PHP-FPM
  - monitoring      # Prometheus-Exporter

Es gibt auch öffentliche Roles im Ansible Galaxy – wie der Marketplace bei GitHub Actions. ansible-galaxy install geerlingguy.nginx installiert eine fertige Webserver-Role.

9) Jinja2-Templates: dynamische Konfig-Dateien

Template-Dateien sind ein mächtiges Feature: du schreibst eine Config-Datei mit Platzhaltern, Ansible füllt die Variablen ein. Verwendet wird Jinja2, dieselbe Template-Sprache wie in Django/Flask:

nginx.conf.j2Jinja2

1server {
2    listen {{ http_port }};
3    server_name {{ ansible_hostname }};
4
5    root /var/www/{{ app_name }};
6
7    {# Bedingung: nur wenn SSL aktiv #}
8    {% if ssl_enabled %}
9    ssl_certificate {{ ssl_cert_path }};
10    {% endif %}
11
12    {# Schleife für Aliases #}
13    {% for alias in server_aliases %}
14    server_alias {{ alias }};
15    {% endfor %}
16}

Templates können Variablen einsetzen ({{ var }}), Bedingungen haben ({% if %}) und Schleifen nutzen ({% for %}). Damit erzeugst du komplexe Config-Dateien dynamisch, je nach Server unterschiedlich. Facts wie ansible_hostname, ansible_os_family, ansible_memory_mb stehen automatisch zur Verfügung – Ansible sammelt sie zu Beginn jedes Plays über das Gathering Facts-Task.

10) Ansible Vault: Geheimnisse schützen

Passwörter und API-Keys gehören nie im Klartext in Playbooks. Ansible Vault verschlüsselt sensible Daten:

terminalBash

1# Verschlüsselte Datei erstellen
2$ ansible-vault create secrets.yml
3New Vault password: ********
4
5# Existierende Datei verschlüsseln
6$ ansible-vault encrypt vars.yml
7
8# Bearbeiten (öffnet im Editor)
9$ ansible-vault edit secrets.yml
10
11# Playbook mit Vault ausführen
12$ ansible-playbook site.yml --ask-vault-pass

Die verschlüsselte Datei kannst du gefahrlos in Git committen – ohne Passwort ist sie nutzlos. Beim Playbook-Run gibst du das Passwort ein (oder lädst es aus einer Passwort-Datei). Mehr zu Krypto in K08.

11) Best Practices

Aus der Praxis – was du tun und lassen solltest:

Roles für Wiederverwendung: nicht alles in ein Mega-Playbook stopfen, in Rollen aufteilen
Group_vars und host_vars: Variablen pro Gruppe oder pro Host in group_vars/ und host_vars/
Tags nutzen: tags: [config] erlaubt selektives Ausführen: --tags config
Check-Mode: --check simuliert die Ausführung ohne Änderungen – „Dry Run"
Diff-Mode: --diff zeigt Datei-Änderungen an
Linter nutzen: ansible-lint prüft Playbooks auf Best-Practice-Verstöße
Vault für Secrets: niemals Passwörter im Klartext
Idempotenz testen: Playbook zweimal laufen lassen – beim zweiten Run sollte alles „ok" sein
Roles aus Ansible Galaxy: für Standard-Setups nicht das Rad neu erfinden

12) Ansible in CI/CD-Pipelines

Ansible wird oft direkt in CI/CD-Pipelines genutzt – z.B. zum Deployment nach einem erfolgreichen Build:

.github/workflows/deploy.ymlGitHub Actions

1name: Deploy via Ansible
2on:
3  push:
4    branches: [main]
5
6jobs:
7  deploy:
8    runs-on: ubuntu-latest
9    steps:
10      - uses: actions/checkout@v4
11
12      - name: Install Ansible
13        run: pip install ansible
14
15      - name: Setup SSH
16        uses: webfactory/ssh-agent@v0.9.0
17        with:
18          ssh-private-key: ${{ secrets.DEPLOY_SSH_KEY }}
19
20      - name: Run playbook
21        run: ansible-playbook -i inventory.yml deploy.yml

So vereinst du Build (CI) und Deploy (Ansible): jeder Push auf main triggert die Pipeline, baut die App, und Ansible konfiguriert die Server und startet die neue Version.

13) Ansible Tower / AWX

Für Enterprise-Umgebungen gibt's Ansible Tower (kommerziell, von Red Hat) bzw. AWX (Open-Source-Variante). Das bietet zusätzlich:

Web-UI für Playbook-Ausführung
Scheduling (regelmäßige Runs)
Rollenbasierte Zugriffsrechte (RBAC)
Audit-Logs (wer hat wann was ausgeführt)
Workflows (mehrere Playbooks verketten)
Notification-Integrationen (Slack, E-Mail)

Für kleine Projekte ist Tower Overkill – da reicht die CLI. Bei größeren Teams mit vielen Playbooks und Compliance-Anforderungen lohnt's sich.

Zusammenfassung

Ansible ist Red Hats Open-Source-Tool für Configuration Management. Agentless – braucht nur SSH und Python auf den Zielservern. Push-Modell: Control Node steuert Managed Nodes. Konzepte: Inventory (Server-Liste mit Gruppen), Playbook (YAML mit Tasks), Module (apt, file, service, template), Roles (wiederverwendbare Task-Sammlungen mit fester Struktur), Handler (Tasks die bei Änderungen ausgelöst werden). Idempotenz ist Schlüsselprinzip: Tasks tun nur was nötig, mehrfaches Ausführen ändert nichts. Templates mit Jinja2 für dynamische Configs. Vault verschlüsselt Secrets. Ansible Galaxy als Marketplace für vorgefertigte Roles. Best Practices: spezifische Module statt shell, Idempotenz testen, Vault für Secrets, ansible-lint nutzen. Sehr beliebt in CI/CD-Pipelines als Deploy-Schritt. Für Enterprise: Tower/AWX mit Web-UI und RBAC.