Begriff
Ansible
Warum wichtig?
Dieser Begriff ist ein Knoten im SengakujiWorks-Wissensnetz. Nutze Level 0 für die erste Einordnung, Level 1 für Praxis, Level 2 für technische Struktur und Level 3 für Grenzen, Fallstricke und Expertenkontext.
Stell dir vor, du hast 100 Server. Auf allen musst du das Passwort von "User B" ändern. Manuell dauert das Tage. Mit Ansible schreibst du einen kleinen Zettel ("Playbook"): "Gehe zu allen Servern. Ändere Passwort von User B auf 'Geheim'." Du drückst Enter. Ansible verbindet sich gleichzeitig mit allen 100 Servern und erledigt das in 10 Sekunden.
Merksatz: Ein Automatisierungstool, das Software installiert, Systeme konfiguriert und Aufgaben auf vielen Servern gleichzeitig ausführt.
Der große Vorteil: Agentless. Du musst auf den Servern nichts installieren. Ansible nutzt einfach SSH (den normalen Zugang), so wie du es manuell tun würdest. Es ist extrem einfach zu lernen (YAML-Format).
Unterschied zu Terraform: Terraform baut das Haus (erstellt den Server). Ansible richtet es ein (installiert Webserver, kopiert Dateien, legt User an).
1. Idempotenz
Wie bei allen guten Tools. Wenn du das Playbook zweimal ausführst: Beim ersten Mal ändert es das Passwort. Beim zweiten Mal sieht es: "Passwort ist schon 'Geheim'. Ich mache nichts." Es zeigt dir am Ende an: "Changed: 0". Das gibt Sicherheit.
2. Inventory
Eine einfache Textdatei, in der steht, welche Server dir gehören.
[webserver]
server1.com
server2.com
[db]
db1.com
Du kannst sagen: "Ansible, mach das Update nur auf der Gruppe [webserver]."
1. Facts und Jinja2 Templating
Bevor Ansible den ersten Task auf einem Server ausführt, sammelt das Setup-Modul sogenannte Facts. Ansible loggt sich ein und fragt den Server komplett aus: "Welches OS bist du? Wie viel RAM hast du? Was ist deine IP?". Diese Hunderten von Variablen werden in einem JSON-Objekt gespeichert. Jetzt kannst du Jinja2 nutzen, um Konfigurationsdateien dynamisch pro Server zu templaten:
listen_address = {{ ansible_default_ipv4.address }}
max_memory = {{ ansible_memtotal_mb / 2 }}
Dieser Ansatz verhindert, dass du 100 verschiedene Config-Dateien für 100 Server pflegen musst.
2. Push vs. Pull Architektur
Tools wie Chef oder Puppet nutzen oft eine Pull-Architektur. Auf jedem Server installiert man einen dicken Agenten, der alle 30 Minuten beim Master-Server nachfragt ("Gibt es neue Befehle für mich?"). Ansible ist eine Push-Architektur. Die Server tun gar nichts. Der Control-Node (oft nur dein Laptop) pusht die Befehle aktiv über SSH (Secure Shell) auf die Maschinen. Vorteil: Kein Overhead, sofortige Ausführung. Nachteil: Wenn ein Server gerade offline ist, wenn du das Playbook pusht, bekommt er das Update nicht.
3. Roles und Ansible Galaxy
Damit Playbooks bei hunderten Vorgängen nicht zu monolithischen YAML-Monstern mutieren, nutzt man Roles. Eine Role zerlegt die Architektur in wiederverwendbare, logische Module (z.B. eine Role "Nginx", eine Role "Postgres"). Man pflegt sie separat in Verzeichnissen. Über Ansible Galaxy (das npm/pip Äquivalent für Ansible) kann man Tausende fertiger, hochqualitativer Roles von anderen Entwicklern (oder offiziell von Herstellern) herunterladen, ohne das Rad für jede Standard-Software neu erfinden zu müssen.
Quick-Check
Brauche ich Programmieren?
Nein. Ansible Playbooks sind simple Listen ("Ensure apache is installed"). Das ist fast wie Englisch lesen.Geht das auch für Windows?
Ja! Ansible nutzt dort WinRM (statt SSH). Es kann Windows-Updates installieren oder Registry-Keys ändern.Was ist Ansible Tower (AWX)?
Eine Web-Oberfläche für Ansible. Damit können auch Nicht-Admins (z. B. der Support) per Knopfdruck komplexe Aufgaben starten ("Server neustarten"), ohne das Passwort zu kennen.