Ansible Grundlagen

Grundsätzliches

• Open-Source Automatisierungs-Werkzeug zur Orchestrierung und allgemeinen Konfiguration und Administration von Computern.
• Es kombiniert Softwareverteilung, Ad-hoc-Kommando-Ausführung und Konfigurationsmanagement.
• Die Verwaltung von Nodes erfolgt über SSH und erfordert keinerlei zusätzliche Software.
• Module nutzen zur Ausgabe JSON und können in jeder beliebigen Programmiersprache geschrieben sein.
• Das System nutzt YAML zur Formulierung wiederverwendbarer Beschreibungen von Systemen.

Geschichte

• Ansible startete im Februar 2012 und die Plattform wurde von Michael DeHaan erstellt.
• Anwender von Ansible sind beispielsweise das Fedora Projekt, Hewlett-Packard Deutschland, Hetzner und die Universität Thessaloniki.
• Ansible ist enthalten in der Fedora-Linux-Distribution des Unternehmens Red Hat Inc.
• Prinzipiell ist Ansible mit allen Unix-artigen Betriebssystemen nutzbar.
• Ab Version 1.7 unterstützen diverse Module auch Windows über Powershell-3.0-Befehle.
• Im Januar 2016 wurde die Version 2.0 veröffentlicht.[5]
• Seit Version 2.10 (2020) ist Ansible in zwei Teile gesplittet: ansible-core (die Engine) und das Paket ansible (Engine + kuratierte Collections).
• Inhalte werden seither überwiegend als Ansible Content Collections über Ansible Galaxy vertrieben statt fest im Kernpaket enthalten zu sein.

AnsibleWorks

Am 4. März 2013 wurde die Firma AnsibleWorks gegründet.

• Sie ist maßgeblich an der Entwicklung von Ansible beteiligt.
• Sie bietet verschiedene Produkte rund um Ansible an, darunter Support und eine Browser-basierte Benutzerschnittstelle.
• Am 16. Oktober 2015 wurde bekanntgegeben, dass Ansible Inc. durch Red Hat Inc. übernommen und in das eigene Portfolio integriert wird.

Architektur

• Wie die meisten anderen Konfigurationsmanagement-Systeme unterscheidet Ansible zwischen Konfigurationsüberwachung und Knoten.
• Auf den Knoten wird die Konfigurationsänderung durchgeführt.
• Diese Knoten werden von Ansible via SSH verwaltet.
• Die Lage der Knoten im Inventar wird von der Konfigurationsüberwachung verwaltet.

Designziele

• minimalistisch
• sicher
• zuverlässig
• leicht erlernbar

Idempotenz

• Zentrales Designprinzip von Ansible: Ein Playbook oder Modul kann beliebig oft ausgeführt werden, das Ergebnis bleibt gleich.
• Ansible prüft vor jeder Änderung den Ist-Zustand und greift nur ein, wenn eine Abweichung vom Soll-Zustand besteht.
• Dadurch unterscheidet sich Ansible von reinen Skript-Ansätzen (z. B. Bash), bei denen ein erneuter Aufruf oft zu Fehlern oder unerwünschten Seiteneffekten führt.

Agentless-Prinzip (Push-Modell)

• Ansible benötigt auf den verwalteten Knoten keine dauerhaft laufende Agenten-Software.
• Die Konfigurationsüberwachung (Control Node) verbindet sich bei Bedarf per SSH und überträgt die auszuführenden Module temporär auf den Zielknoten.
• Nach Ausführung wird das Modul wieder entfernt.

Abgrenzung

• Puppet und Chef arbeiten im Pull-Modell: Ein auf dem Knoten dauerhaft installierter Agent fragt periodisch beim zentralen Server nach Konfigurationsänderungen.
• Vorteil des Push-Modells: geringere Angriffsfläche (kein zusätzlicher Dienst), einfacheres Onboarding neuer Knoten, keine Agenten-Wartung/-Updates nötig.

Voraussetzungen auf dem Zielknoten

• SSH-Zugriff (i. d. R. Public-Key-Authentifizierung)
• Python-Interpreter (wird von den meisten Modulen zur Ausführung benötigt; Ausnahme: Raw-Modul und einige Windows-Module)
• Bei privilegierten Aktionen: sudo bzw. become-Rechte für den verbindenden Benutzer

Inventar

• Das Inventar ist eine Beschreibung der Knoten, auf die von Ansible zugegriffen werden kann.
• Standardmäßig wird das Inventar durch eine Initialisierungsdatei beschrieben.
• Die Konfigurationsdatei listet entweder die IP-Adresse oder den Hostnamen jedes Knotens auf.
• Knoten können auch gruppiert werden.

Ad-hoc-Kommandos

• Einzelne Befehle, ohne Playbook, direkt über die Kommandozeile ausgeführt.
• Sinnvoll für schnelle Prüfungen, einmalige Aktionen oder Debugging.
• Grundsyntax: Zielgruppe, ausführendes Modul und dessen Argumente werden direkt an ansible übergeben.

Privilege Escalation (become)

• Mit become führt Ansible Aufgaben auf dem Zielknoten mit erhöhten Rechten aus (standardmäßig via sudo).
• Steuerbar über become, become_user und become_method (sudo, su, doas, …).
• Kann sowohl in Ad-hoc-Kommandos als auch später in Playbooks gesetzt werden.

Playbooks

• Playbooks beschreiben Konfiguration, Deployment und Orchestrierung in Ansible.
• Das Playbook-Format ist YAML, wobei jedes Playbook eine Gruppe von Hosts zu einer Reihe von Rollen zuordnet.
• (wird in einem eigenen Kapitel vertieft)

ansible-vault

• Werkzeug zur Verschlüsselung sensibler Daten (Passwörter, API-Keys, Zertifikate) innerhalb von Ansible-Dateien.
• Verschlüsselte Dateien können bedenkenlos in einem Git-Repository versioniert werden.
• Das Vault-Passwort kann interaktiv abgefragt oder aus einer Datei bzw. einem externen Skript gelesen werden, was sich für Automatisierung/CI eignet.

Konfigurationsdatei (ansible.cfg)

• Steuert das Verhalten von Ansible global oder projektbezogen.
• Suchreihenfolge: ANSIBLE_CONFIG-Umgebungsvariable → ./ansible.cfg im aktuellen Verzeichnis → ~/.ansible.cfg → /etc/ansible/ansible.cfg

AWX

• AWX ist eine REST-API, ein Web-Service und eine Web-basierte Konsole.
• Damit kann die mit Ansible verwaltete IT-Infrastruktur zentralisiert werden.
• AWX ist das Upstream-Projekt (Open Source) zur kommerziellen Red Hat Ansible Automation Platform (AAP).
• In Bundeswehr-/Behörden-Umgebungen begegnet einem in der Praxis eher AAP als AWX, da Red Hat dafür Support-Verträge anbietet.

Quellen

• https://de.wikipedia.org/wiki/Ansible