# Ansible Roles: Struktur & Modularität für Enterprise-Automatisierung

TL;DR / Management Summary Ein Playbook mit 1000 Zeilen Code ist unlesbar und schwer zu warten. Ansible Roles erlauben es, Aufgaben (Tasks), Variablen, Templates und Dateien in einer standardisierten Ordnerstruktur zu bündeln. Ein Senior Admin nutzt Roles, um Funktionen (z.B. “MySQL-Server” oder “Hardened-SSH”) einmal zu schreiben und in vielen verschiedenen Projekten wiederzuverwenden. Dies fördert das DRY-Prinzip und ermöglicht die Nutzung von tausenden fertigen Community-Rollen via Ansible Galaxy.

# 1. Was ist eine Role?

Die Funktionseinheit.

Eine Role ist eine vordefinierte Struktur von Verzeichnissen:

tasks/main.yml: Die Liste der Aufgaben.
handlers/main.yml: Neustart-Logik.
vars/main.yml: Feste Variablen.
defaults/main.yml: Standardwerte (leicht überschreibbar).
templates/: Jinja2 Vorlagen.
files/: Statische Dateien (z.B. Skripte oder Logos).

# 2. Rollen in Playbooks nutzen

Der Aufruf.

Anstatt Tasks direkt ins Playbook zu schreiben, rufen wir die Rolle auf:

---
- name: Deploy Web Stack
  hosts: all
  roles:
    - common_base_hardening
    - nginx_server
    - { role: postgres_db, db_name: 'prod_db' }

# 3. Deep Dive: ‘defaults’ vs. ‘vars’

Die Hierarchie der Macht.

Ansible hat eine komplexe Prioritätenliste für Variablen. Innerhalb einer Rolle:

defaults/: Hier liegen Werte, die der User des Playbooks überschreiben darf (z.B. Portnummern).
vars/: Hier liegen feste Werte, die für die Funktion der Rolle kritisch sind und meist nicht geändert werden sollten.
Best Practice: Nutzen Sie immer defaults/main.yml, um Ihre Rollen so flexibel wie möglich zu gestalten.

# 4. Day-2 Operations: Ansible Galaxy

Kein Rad neu erfinden.

Galaxy ist der App-Store für Ansible-Rollen.

Aktion: Suchen Sie nach Rollen von Herstellern (z.B. geerlingguy.mysql oder elastic.elasticsearch).
Installation:

ansible-galaxy install geerlingguy.docker

Vorteil: Sie profitieren vom Sicherheits-Know-how tausender anderer Admins.

# 5. Troubleshooting & “War Stories”

Wenn die Abstraktion verwirrt.

# Top 3 Fehlerbilder

Symptom: “Role not found”.
- Ursache: Falscher Suchpfad für Rollen.
- Lösung: Pfad in der ansible.cfg unter roles_path anpassen.
Symptom: Variablen werden von einer anderen Rolle überschrieben.
- Ursache: Identische Variablennamen in verschiedenen Rollen (Namespace-Problem).
- Lösung: Präfixe nutzen (z.B. nginx_port statt nur port).
Symptom: handlers werden nicht getriggert.
- Ursache: Der notify Name stimmt nicht exakt mit dem Namen im handlers/main.yml überein.

# “War Story”: Die “Schatten”-Role aus dem Internet

Ein Admin installierte eine ungetestete Rolle aus Galaxy für ein Monitoring-Tool. Das Ereignis: Die Rolle enthielt einen Task, der die gesamte Firewall (iptables) am Host zurücksetzte, um seine eigenen Ports zu öffnen. Das Ergebnis: Alle anderen produktiven Dienste auf dem Host waren schlagartig vom Netz abgeschnitten. Lehre: Prüfen Sie jede externe Rolle vor dem Einsatz in Produktion. Nutzen Sie nur Rollen von vertrauenswürdigen Autoren oder kopieren Sie den Code in Ihr eigenes Repository (Vendoring), um die Kontrolle zu behalten.

# 6. Monitoring & Reporting

Rollen-Audit.

# Ansible Lint

Prüfen Sie Ihre Rollen auf Einhaltung der Standards:

ansible-lint roles/my_custom_role

KPI: Anzahl der Verstöße gegen Best-Practices (z.B. “Missing name for task”).

# 7. Fazit & Empfehlung

Rollen machen Ansible erst professionell.

Empfehlung: Bauen Sie eine Base-Role, die jeder Server im Unternehmen bekommt (SSH-Keys, NTP, Monitoring-Agent).
Wichtig: Nutzen Sie die Datei meta/main.yml, um Abhängigkeiten zu definieren (z.B. “Diese App-Rolle braucht zwingend die Java-Rolle”).

# Anhang: Struktur-Vorlage (Ansible-Galaxy Init)

# Erstellt ein leeres Rollen-Gerüst
ansible-galaxy role init my_new_role