Systemmanagement: Red Hat Ansible Automation Platform 2.0 im Test

Mit Ansible Automation Platform 2.0 spaltet Red Hat das ehemalige Ansible Tower in separate Module auf und betont so die Bedeutung des Automatisierungstools.

Artikel verschenken
In Pocket speichern vorlesen Druckansicht
Lesezeit: 14 Min.
Von
  • Daniel Kobras
  • Mark Pröhl
Inhaltsverzeichnis

Ob Web-GUI oder grafische Oberfläche – wer über Red Hats Ansible Tower oder das zugehörige Open-Source-Projekt AWX liest, gewinnt leicht den Eindruck, es handele sich lediglich um eine schlichte Erweiterung des Automatisierungswerkzeugs Ansible für Kommandozeilenverächter. Dabei arbeiten die wesentlichen Komponenten hinter den Kulissen. Um ihre Bedeutung zu verstehen, ist zunächst ein Blick auf die Grundlagen der Ansible-Architektur nötig.

Mehr zum Thema Systemmanagement:

Im Unterschied zu anderen Konfigurationswerkzeugen wie Puppet oder SaltStack verwendet Ansible keine eigenen Dienste oder Kommunikationsprotokolle. Im Normalfall genügen Python-Interpreter und SSH- oder WinRM-Zugang, um eine Maschine mit Ansible zu verwalten. Doch dieser leichtgewichtige Ansatz ist Fluch und Segen zugleich.

Zwar fällt der Umstieg von der interaktiven Turnschuhadministration besonders leicht, wenn auf den zu verwaltenden Clients keine Installationsschritte anfallen. Aber wenn die Ansprüche an die Administration wachsen, ist viel Disziplin angesagt: Beispielsweise sollen Änderungen am System in vielen Umgebungen stets automatisiert und nachvollziehbar erfolgen. In größeren IT-Teams darf etwa der Helpdesk nur ausgewählte, vordefinierte Aktionen ausführen, hier ist eine möglichst rollenbasierte Berechtigungsvergabe gefragt. Für stets reproduzierbare Ergebnisse beim Ausführen von Playbooks wiederum müssen Einflüsse durch externe Faktoren ausgeschlossen sein.