Ansible lernen: Konfiguration automatisieren

Wenn du mehr als ein paar Server verwaltest, kommst du um Automatisierung nicht herum. Ansible ist dafür ein Werkzeug, das du mit normalem SSH-Zugang in den Griff bekommst, ohne Agenten und ohne riesigen Overhead. Entscheidend ist, dass du die Kernbausteine verstehst: Inventories, Playbooks, Module, Rollen, Idempotenz und Vault.

Was Ansible für Admins so attraktiv macht

Ansible setzt auf ein einfaches Prinzip: Du beschreibst den gewünschten Zustand, Ansible kümmert sich um den Weg dorthin.

Typische Aufgaben, bei denen dir Ansible Arbeit abnimmt:

• Paketinstallation und Updates auf vielen Servern
• Benutzerverwaltung und SSH-Keys ausrollen
• Konfigurationsdateien verteilen und templaten
• Dienste neu starten, wenn sich Konfigurationen ändern
• Server von Grund auf provisionieren
• Wiederkehrende Wartungsjobs durchführen

Du musst dir nicht mehr merken, was du auf welchem Server manuell angepasst hast. Stattdessen landet alles in Playbooks, die nachvollziehbar und versionierbar sind, zum Beispiel in Git. Gerade in gewachsenen Umgebungen, wie man sie bei vielen Münchner Unternehmen sieht, ist das Gold wert.

Inventories: Welche Hosts gibt es überhaupt?

Das Inventory ist dein Verzeichnis der Zielsysteme. Ohne Inventory weiß Ansible nicht, wohin es sprechen soll.

Es gibt zwei Hauptformen:

• Statisches Inventory: einfache INI- oder YAML-Datei
• Dynamisches Inventory: Skript oder Plugin, das Hosts z. B. aus AWS, VMware oder einer CMDB zieht

Ein simples statisches Inventory in INI-Form könnte so aussehen:

[webserver]
web01.example.local
web02.example.local

[dbserver]
db01.example.local

[all:vars]
ansible_user=admin
ansible_ssh_common_args='-o StrictHostKeyChecking=no'

Wichtige Punkte:

• Gruppen wie „webserver“ oder „dbserver“ helfen dir, Playbooks gezielt auf Hostmengen anzuwenden.
• Untergruppen sind möglich, etwa „prod“ und „staging“.
• Mit all:vars oder gruppenspezifischen Variablen steuerst du Standardwerte, etwa den SSH-Benutzer.

Mit YAML-Inventories kannst du noch strukturierter arbeiten, zum Beispiel, wenn du viele Variablen pro Host hast. Für den Einstieg ist INI aber völlig ausreichend.

Playbooks: Deine Abläufe als Code

Playbooks sind das Herzstück von Ansible. Sie beschreiben, was auf welchen Hosts passieren soll. Technisch sind es YAML-Dateien mit Plays, und jedes Play besteht aus Tasks.

Ein sehr reduziertes Beispiel:

- name: Webserver konfigurieren
 hosts: webserver
 become: true

 tasks:
 - name: Apache ist installiert
 ansible.builtin.package:
 name: apache2
 state: present

 - name: Service ist gestartet und aktiviert
 ansible.builtin.service:
 name: apache2
 state: started
 enabled: true

Was du daran sehen solltest:

• hosts: bestimmt die Zielgruppe, hier die Gruppe „webserver“ aus dem Inventory.
• become: true: führt Tasks mit erhöhten Rechten aus, meist via sudo.
• Jede - name:-Zeile beschreibt eine Task verständlich für Menschen.
• Tasks nutzen Module, nicht Shell-Hacks, wenn es sich vermeiden lässt.

Ein Playbook ersetzt deine handschriftlichen Notizen und „One-Liner-Sammlungen“. Du kannst es immer wieder ausführen, auf neuen oder bestehenden Servern, und bekommst konsistente Ergebnisse.

Module: Bausteine statt Shell-Skripte

Ansible-Module sind vorbereitete Bausteine für typische Admin-Aufgaben. Du sagst nicht „führe diesen Befehl aus“, sondern „Paket X soll installiert sein“ oder „Datei Y soll mit diesem Inhalt existieren“.

Wichtige Modultypen:

• System: package, service, user, group, cron
• Dateien: file, copy, template, lineinfile
• Netzwerk: Module für Switches, Firewalls, Load Balancer
• Cloud: Module für AWS, Azure, GCP, VMware usw.

Beispiele:

- name: Benutzer anlegen
 ansible.builtin.user:
 name: deploy
 shell: /bin/bash
 state: present

- name: Konfigurationsdatei kopieren
 ansible.builtin.copy:
 src: files/app.conf
 dest: /etc/app/app.conf
 owner: root
 group: root
 mode: "0644"

Du kannst zwar jederzeit ansible.builtin.shell oder ansible.builtin.command benutzen, aber die Stärke von Ansible liegt in den Modulen. Sie sind in der Regel idempotent und liefern strukturierte Rückgaben, etwa ob sich etwas geändert hat.

Idempotenz: Mehrmals ausführen ohne Chaos

Idempotenz bedeutet: Du kannst ein Playbook beliebig oft laufen lassen, ohne ungewollte Nebenwirkungen. Wenn der gewünschte Zustand schon erreicht ist, macht Ansible nichts mehr.

Beispiele:

• package: state: present installiert ein Paket nur, wenn es noch fehlt.
• file: state: directory legt ein Verzeichnis nur an, wenn es noch nicht existiert.
• service: state: started startet den Dienst nur, wenn er nicht schon läuft.

Vorteile für dich:

• Du kannst Playbooks bedenkenlos erneut ausführen, etwa nach einer Änderung in einem Teilbereich.
• Du erkennst an der Ausgabe, welche Tasks tatsächlich etwas geändert haben.
• Du kannst Deployments automatisieren, ohne Angst vor „Doppelausführung“ zu haben.

Typische Fehlerquelle bei Einsteigern: Shell-Befehle, die nicht idempotent sind, etwa blind echo "foo" >> /etc/datei in einer Task. Besser: ein geeignetes Modul wie lineinfile verwenden, das prüft, ob die Zeile schon existiert.

Rollen: Ordnung in größeren Playbooks

Sobald dein Playbook mehr als ein paar Dutzend Tasks hat, wird es unübersichtlich. Rollen helfen dir, Struktur und Wiederverwendbarkeit reinzubringen.

Eine Rolle hat eine standardisierte Verzeichnisstruktur, zum Beispiel:

roles/
 webserver/
 tasks/
 main.yml
 templates/
 vhost.conf.j2
 files/
 index.html
 vars/
 main.yml
 handlers/
 main.yml

Idee dahinter:

• tasks/main.yml: Einstiegspunkt für alle Tasks der Rolle.
• templates/: Jinja2-Templates, z. B. Konfigurationsdateien mit Variablen.
• files/: Dateien, die 1:1 kopiert werden.
• handlers/: Aktionen, die auf „notify“ reagieren, etwa Dienstneustarts.

Ein Playbook, das eine Rolle verwendet, bleibt schlank:

- name: Webserver-Rolle anwenden
 hosts: webserver
 become: true

 roles:
 - webserver

Warum das für dich praktisch ist:

• Du kannst Rollen zwischen Projekten teilen.
• Teams können an unterschiedlichen Rollen arbeiten, ohne sich in einem riesigen Playbook zu verheddern.
• Du kapselst Komplexität, etwa eine komplette Datenbankinstallation, hinter einem Rollenaufruf.

Gerade wenn du in größeren Umgebungen in München mit mehreren Admins arbeitest, werden Rollen schnell zum Standard, um Wartbarkeit sicherzustellen.

Variablen, Templates und Handlers: Feinsteuerung

Ohne Variablen und Templates wäre Ansible viel weniger flexibel.

Typische Verwendung:

• Host- oder gruppenspezifische Einstellungen, etwa Ports, Pfade, Umgebungen.
• Templates für Konfigurationsdateien mit Platzhaltern.

Ein Template app.conf.j2 könnte so aussehen:

environment={{ app_env }}
port={{ app_port }}

Die zugehörige Task:

- name: App-Konfiguration aus Template
 ansible.builtin.template:
 src: app.conf.j2
 dest: /etc/app/app.conf
 notify: App neu starten

Der notify-Eintrag verweist auf einen Handler:

handlers:
 - name: App neu starten
 ansible.builtin.service:
 name: app
 state: restarted

Das Muster ist wichtig: Dienste werden nur neu gestartet, wenn sich die Konfiguration geändert hat. Auch das ist ein Beitrag zur Idempotenz und vermeidet unnötige Unterbrechungen.

Vault: Geheimnisse sicher verwalten

Früher oder später brauchst du Passwörter, API-Keys oder Zertifikate in deinen Playbooks. Die solltest du nicht im Klartext in Git legen. Genau hier kommt Ansible Vault ins Spiel.

Vault verschlüsselt sensible Inhalte, zum Beispiel:

• komplette Variablen-Dateien
• einzelne Variablen innerhalb von Dateien
• auch ganze Playbooks, falls nötig

Typischer Workflow:

1. Du erstellst eine Variablendatei, z. B. group_vars/dbserver/vault.yml.
2. Mit ansible-vault encrypt verschlüsselst du sie.
3. Im Playbook verwendest du die Variablen ganz normal, z. B. db_password: "{{ vault_db_password }}".
4. Beim Ausführen des Playbooks gibst du das Vault-Passwort an oder verwendest eine Passwortdatei mit passenden Berechtigungen.

Wichtig in der Praxis:

• Nur so viel wie nötig verschlüsseln, nicht alles.
• Klare Regeln im Team, wer das Vault-Passwort kennt.
• Vault-Dateien wie andere Konfigurationen versionieren, aber auf die Rechte achten.

So kannst du Playbooks sicher in einem Repository teilen, ohne deine Infrastruktur-Schlüssel zu verschenken.

Wo Ansible dir konkret Arbeit abnimmt

Ein paar typische Szenarien aus dem Admin-Alltag:

Onboarding neuer Server

• Basis-Pakete installieren
• Standard-User und SSH-Keys anlegen
• Logging- und Monitoring-Agenten ausrollen
• Firewall-Regeln setzen

Einmal sauber als Playbook umgesetzt, brauchst du für neue Maschinen nur noch: Inventory-Eintrag erstellen, Playbook starten, fertig.

Patch- und Update-Management

• Auf allen Webservern Sicherheitsupdates einspielen
• Danach Webserver nur dort neu starten, wo wirklich etwas geändert wurde
• Statusberichte aus der Ansible-Ausgabe ableiten

Du sparst dir, dich auf jeden Server einzuloggen, und reduzierst das Risiko, einen Knoten zu vergessen.

Konfiguration konsistent halten

• Gleiche NTP-, DNS- oder Proxy-Konfiguration auf allen Hosts
• Einheitliche Logrotate-Policies
• Standardisierte Systemd-Units für eigene Dienste

Wenn jemand manuell etwas ändert, kannst du das Playbook erneut laufen lassen und die Abweichung korrigieren.

Anwendungen deployen

• Paketabhängigkeiten und Systemnutzer anlegen
• Konfigurationsdateien aus Templates pro Umgebung generieren
• Dienste mit Handlers kontrolliert neu starten
• Optional: mit Tags nur Teilbereiche ausführen, etwa nur „config“ oder nur „deploy“

Damit kommst du schnell weg von „Handarbeit plus Copy&Paste“ hin zu reproduzierbaren Releases.

Einstieg und sinnvolle nächste Schritte

Um Ansible wirklich zu beherrschen, solltest du dir ein kleines, aber echtes Projekt vornehmen, zum Beispiel:

1. Zwei Test-VMs aufsetzen, etwa eine „webserver“- und eine „dbserver“-Gruppe.
2. Ein Inventory anlegen und das SSH-Basissetup testen.
3. Ein Playbook bauen, das Basis-Pakete und Benutzer ausrollt.
4. Eine kleine Rolle „webserver“ erstellen, die einen Webserver installiert und eine einfache Seite ausliefert.
5. Vault nutzen, um ein Datenbankpasswort zu verwalten.

Aktuelle Termine und passende Kurse findest du bei cmt.de.

Als Referenz lohnt sich ein Blick in die offizielle Dokumentation und Ansible-Collections, um passende Module für deine Umgebung zu finden. Mit wachsender Erfahrung wirst du merken: Je konsequenter du Inventories, Rollen, Idempotenz und Vault einsetzt, desto weniger „Feuerwehraktionen“ brauchst du im Alltag.