# Ansible Basics: Die Revolution der agentenlosen Automatisierung

TL;DR / Management Summary Ansible ist das populärste Open-Source Werkzeug für das Konfigurationsmanagement und die Applikations-Orchestrierung. Sein größter Vorteil: Es ist agentenlos. Sie müssen auf den Ziel-Servern (z.B. Ihren Proxmox-VMs) keine Software vorinstallieren. Ansible nutzt Standard-Protokolle wie SSH (für Linux) oder WinRM (für Windows). Ein Senior Admin nutzt Ansible, um tägliche Routine-Aufgaben (Updates, User-Management) konsistent über hunderte Server hinweg zu automatisieren.

# 1. Wie Ansible funktioniert

Push statt Pull.

Im Gegensatz zu Systemen wie Puppet oder Chef arbeitet Ansible nach dem Push-Modell:

1. Control Node: Ihr Management-PC oder ein zentraler CI/CD-Server. Hier liegt Ansible.
2. Inventory: Eine Liste der Ziel-Server (IPs oder Hostnamen).
3. Modules: Kleine Skripte, die Ansible auf die Ziel-Server kopiert, dort ausführt und wieder löscht.
4. YAML: Die Sprache der Konfiguration. Einfach zu lesen, schwer zu fehlinterpretieren.

# 2. Das Inventar (Inventory)

Wer ist das Ziel?

Die einfachste Form ist eine hosts.ini:

[webservers]
web01.firma.local
web02.firma.local

[dbservers]
db01.firma.local ansible_host=10.0.1.50

• Profi-Weg: Nutzen Sie ein Dynamisches Inventory (Artikel 714), um Server automatisch aus Proxmox zu laden.

# 3. Deep Dive: Idempotenz

Das wichtigste Konzept.

Ein Ansible-Modul prüft immer erst den Ist-Zustand.

• Befehl: apt: name=nginx state=present.
• Aktion: Wenn Nginx schon installiert ist, tut Ansible nichts.
• Vorteil: Sie können Ihre Playbooks beliebig oft ausführen, ohne das System in einen inkonsistenten Zustand zu bringen.

# 4. Day-2 Operations: Ad-hoc Kommandos

Schnelle Hilfe ohne Playbook.

Manchmal muss es schnell gehen. Nutzen Sie Ansible wie eine Multi-Shell:

# Prüft die Uptime aller Webserver
ansible webservers -m shell -a "uptime"

# Startet den Nginx Dienst auf allen Knoten neu
ansible webservers -m service -a "name=nginx state=restarted" -b

• -b: Steht für become (Führe als sudo/root aus).

# 5. Troubleshooting & “War Stories”

Wenn die Shell rot sieht.

# Top 3 Fehlerbilder

1. Symptom: “UNREACHABLE” Fehlermeldung.

   • Ursache: SSH-Key nicht hinterlegt oder IP-Adresse falsch.
   • Lösung: ssh user@host manuell testen.

2. Symptom: “Missing sudo password”.

   • Lösung: Konfigurieren Sie den User in /etc/sudoers.d/ für passwortloses Sudo oder nutzen Sie --ask-become-pass.

3. Symptom: Script bricht bei 100 VMs ab (Timeout).

   • Fix: Erhöhen Sie die Anzahl der parallelen Prozesse via -f 20 (Forks).

# “War Story”: Der “Double-Entry” im Host-Key

Ein Admin installierte eine VM neu, behielt aber die gleiche IP. Das Ereignis: Ansible weigerte sich, Befehle auszuführen (“Host key verification failed”). Die Ursache: In der known_hosts Datei des Control-Nodes war noch der alte Key der gelöschten VM gespeichert. Die Gefahr: Der Admin deaktivierte die Key-Prüfung global in der ansible.cfg (host_key_checking = False). Dies öffnete die Tür für Man-in-the-Middle Angriffe im LAN. Lehre: Nutzen Sie gezielte Bereinigungs-Befehle (ssh-keygen -f "~/.ssh/known_hosts" -R "10.0.1.50") statt Sicherheits-Features global abzuschalten.

# 6. Monitoring & Reporting

Statistiken der Läufe.

# Ansible Callback Plugins

Aktivieren Sie Plugins wie profile_tasks, um zu sehen, welcher Schritt am längsten dauert.

• KPI: Playbook Duration. (Sollte bei Standard-Wartung < 5 Min liegen).

# 7. Fazit & Empfehlung

Ansible ist das zugänglichste Automatisierungs-Tool am Markt.

• Empfehlung: Nutzen Sie Ansible für alles, was Sie öfter als zweimal tun müssen.
• Wichtig: Versionieren Sie Ihre Playbooks in Git (Artikel 420b). Jede Server-Änderung muss einen Code-Commit haben.

# Anhang: Cheatsheet (Ansible CLI)

# Referenzen

• Ansible Official Documentation
• Ansible Galaxy: Community Roles Hub
• Red Hat: What is Ansible?