Einführung in Ansible

Ansible steuert entfernte Linux-Systeme zentral von einem Control Node, ohne dort einen Ansible-Agenten zu installieren. Sie lernen das Zusammenspiel von Managed Nodes, Inventory, Verbindung und Modulen sowie die Anforderungen an SSH und Zugangsdaten kennen. Anschließend grenzen Sie Configuration Management von Provisioning und agentenbasierten Betriebsmodellen ab.

Der Control Node benötigt ansible-core und passende Verbindungsdaten für die verwalteten Systeme. Im DevNinjas Dojo, unserer Cloud-Lernumgebung, installieren Sie das Paket, richten SSH-Schlüssel ein und prüfen mehrere Managed Nodes mit dem Ansible-Ping-Modul. Danach untersuchen Sie ausgewählte Einstellungen in ansible.cfg und ordnen Konfigurationsdatei, Inventory und Kommandozeile ihren Aufgaben zu.

Das Inventory beschreibt verwaltete Systeme und ordnet sie logischen Gruppen zu. Sie erstellen Varianten in INI und YAML, gruppieren Web- und Datenbank-Hosts und definieren Host- sowie Gruppenvariablen. Mit verschachtelten Gruppen und den Verzeichnissen group_vars und host_vars untersuchen Sie, wie Zielauswahl und Konfigurationsdaten getrennt strukturiert werden.

Ad-hoc-Kommandos führen einzelne Module ohne gespeichertes Playbook aus. Sie verwenden Module für Pakete, Services und Dateien auf ausgewählten Inventory-Gruppen und lesen ihre Parameter mit ansible-doc. Durch wiederholte Ausführung vergleichen Sie Change-Status und Idempotenz, ohne daraus eine allgemeine Garantie für jedes Modul oder beliebige Shell-Kommandos abzuleiten.

Playbooks beschreiben Plays und geordnete Tasks in YAML für klar strukturierte Konfigurationsabläufe. Sie üben Einrückung, Listen und Dictionaries kontrolliert und erstellen ein Playbook für Pakete, Benutzer und eine Konfigurationsdatei. Bei der Ausführung mit ansible-playbook untersuchen Sie Zielauswahl, Modulparameter sowie die Statusmeldungen ok, changed und failed.

Variablen können aus Inventory, Playbook, Role oder Kommandozeile stammen und folgen dokumentierten Vorrangregeln. Sie vergleichen ausgewählte Quellen, sammeln Systeminformationen als Facts und speichern ein Task-Ergebnis mit register. Anschließend verwenden Sie die Daten in einer späteren Aufgabe und unterscheiden dauerhaft definierte Variablen von Ergebnissen der aktuellen Playbook-Ausführung.

Playbooks können Tasks anhand von Variablen, Facts oder vorherigen Ergebnissen auswählen und Datenlisten wiederholt verarbeiten. Sie kombinieren in einem Playbook when, Loops und Handler, sodass ein Service nur nach einer gemeldeten Änderung benachrichtigt wird. Mit block und rescue strukturieren Sie zusammengehörige Aufgaben und untersuchen kontrollierte Fehlerpfade.

Hostnamen, IP-Adressen und Ports können sich zwischen Umgebungen unterscheiden; Jinja2 Templates verbinden statischen Konfigurationstext mit Variablen und Facts, die Ansible auf dem Control Node verarbeitet. Sie setzen Werte ein, durchlaufen Listen und transformieren Daten mit ausgewählten Filtern. In der Lernumgebung entwickeln Sie eine Nginx-Konfiguration für unterschiedliche Hosts.

Ansible Vault verschlüsselt Variablen und Dateien, damit sensible Werte nicht als Klartext im Repository liegen. Sie erzeugen verschlüsselte Inhalte, verwenden Vault-IDs und stellen ein Passwort für die Playbook-Ausführung bereit. Dabei halten Sie fest, dass Vault Daten im Ruhezustand schützt und entschlüsselte Werte, Ausgaben sowie Passwortquellen zusätzliche Schutzmaßnahmen benötigen.

In einem zusammenhängenden Szenario installieren und konfigurieren Sie Nginx mit einem Playbook. Variablen steuern Port und Servername, ein Jinja2 Template erzeugt die Konfiguration, ein Modul behandelt Firewall-Regeln und ein Handler reagiert auf Änderungen. Sie führen das Playbook gemeinsam wiederholt aus und untersuchen Status sowie Erreichbarkeit.

Roles bündeln Tasks, Handler, Variablen, Dateien und Templates in einer bekannten Verzeichnisstruktur. Sie erzeugen eine Role mit ansible-galaxy, überführen das Webserver-Playbook und unterscheiden Defaults von Variablen mit höherem Vorrang. Danach verwenden Sie die Role in einem Play und untersuchen, wann Role-Dependencies geeignet oder unnötig eng gekoppelt sind.

Ansible Galaxy verteilt Community-Inhalte als Roles und Collections. Sie vergleichen beide Formate, binden vorbereitete Inhalte über eine Requirements-Datei ein und installieren eine Collection. Dabei unterscheiden Sie die mit ansible-core bereitgestellte Collection ansible.builtin von separat installierten Collections und ordnen ein, dass Community-Inhalte vor dem Einsatz an den eigenen Betriebs- und Sicherheitsanforderungen gemessen werden müssen.

Automatisierungsinhalte lassen sich statisch prüfen und vor einer Änderung mit Check Mode sowie Diff untersuchen. Sie führen ansible-lint gemeinsam auf dem Projekt aus und vergleichen normalen Lauf, Check Mode und Diff. Dabei berücksichtigen Sie, dass Modulunterstützung variiert und diese Prüfungen weder Integrationstests noch Reviews ersetzen.

Das Abschlussprojekt verbindet Inventory-Gruppen, Variablen, Templates und Roles über mehrere Linux-Hosts. Sie strukturieren eine Datenbank, einen Application Server und einen Nginx-Loadbalancer als getrennte Verantwortungsbereiche und führen das gemeinsame Playbook aus. Danach untersuchen Sie gezielt Abhängigkeiten und wiederholte Ausführung, ohne daraus Produktionsreife oder unbegrenzte Übertragbarkeit abzuleiten.

Für gemeinsame Ausführung und Governance kommen nach lokalen Playbooks weitere Komponenten infrage. Sie ordnen AWX als Oberfläche und API für Automatisierungsjobs, Execution Environments als containerisierte Laufzeitpakete und CI/CD als möglichen Auslöser ein. Sie erhalten eine Orientierung, welche dieser Themen für Ihren Automatisierungsweg relevant sind, ohne AWX oder eine produktive Pipeline einzurichten.