Ansible – the after shell und warum es heute keinen Grund mehr gibt, nicht zu automatisieren
Wer heute mit IT-Infrastruktur, Netzwerken oder Servern arbeitet, steht vor einer unüberschaubaren Vielfalt an Tools, Methoden und Versprechen: Virtualisierung, Containerisierung, Infrastructure as Code, DevOps, GitOps, Platform Engineering – und täglich kommen neue Schlagwörter hinzu. Dabei ist der eigentliche Bedarf oft viel einfacher: Es geht darum, wiederholbare Abläufe effizient, nachvollziehbar und zuverlässig umzusetzen. Kurz: Automatisieren.
Automatisierung ist keine Kür mehr, sondern Voraussetzung für Skalierbarkeit, Stabilität und Wartbarkeit. Und das Beste: Sie ist heute so zugänglich wie nie. Grade in der IT hat das Eingeben von Befehlen einen festen Bestandteil im täglichen Tun. Auch wenn man es manchmal hinter Webanwendungen oder Formularen verteckt, so läuft im Hintergrund etwas ab, dass etwas für uns tut. Wer einmal mit der Kommandozeile gearbeitet hat, bringt bereits das nötige Rüstzeug mit. Der nächste logische Schritt? Ansible.
Vorteile von Ansible zur Automatisierung
Ansible ist mehr als ein Tool – wenn man es zulässt. Es bietet eine Art und Weise um einmal gefundene Konfigurationen und Abläufe festzuhalten und damit die Grundlage für Wiederholbarkeit zu schaffen.
“Was ich auf der Shell mache, schreibe ich mir direkt als Ansible-Playbook auf.”
So könnte das Motto lauten. Statt mühsam Befehle zu rekonstruieren oder manuell zu wiederholen, wird Wissen sofort in wiederverwendbare Automatisierung überführt. Kein Agent, keine Datenbank, keine komplexe IDE ist dafür notwendig.
Ansible ist die Shell nach der Shell. Ein Werkzeug, das den spontanen Einzeiler mit dem robusten Automatisierungsansatz verbindet.
„Ich bin kein Entwickler.“ – zählt nicht mehr!
Automatisierung ist keine reine Entwicklerdomäne. Ansible spricht eine Sprache, die auch ohne Programmier-Background funktioniert. Für Administratoren und Architekten, die ohnehin in technischen Umgebungen arbeiten ist YAML leicht lesbar, logisch strukturiert – und wer Shell versteht, versteht auch, was in einem sogenannten Playbook passiert. Der Weg von der Idee zur Automatisierung ist kurz. Sehr kurz.
Wer einmal angefangen hat, merkt schnell, wie viel sich mit wenig Aufwand erreichen lässt. Routine wird reproduzierbar. Know-how wird dokumentiert. Zusammenarbeit wird einfacher.
Die gemeinsame Sprache in heterogenen Teams
Egal ob Admin, Entwickler, DevOps-Engineer oder IT-Manager – je größer ein Team, desto wichtiger ist eine gemeinsame Basis. In Meetings gehen oft Stunden verloren, weil sich alle Beteiligten erstmal auf eine Abstraktionsebene einigen müssen. Mit Ansible wird dieser Dialog einfacher: Textbasierte Playbooks sind konkret, nachvollziehbar und versionierbar.
Wer ein Playbook liest, versteht sofort:
Schnellstart: Ansible aus dem Stand
Die Einstiegshürde in Ansible ist bemerkenswert niedrig:
ansible all -i meinhost, -m ping
Das Ergebnis? Ein einfacher Ping an ein Zielsystem – über SSH, ohne Agent.
Mit einem Kommando ein System ansprechen, testen, konfigurieren – oder Pakete installieren:
ansible all -i meinhost, -m yum -a „name=httpd state=present“ -u root -k
| Parameter | Bedeutung |
|---|---|
| -i meinhost, | Das Inventar – hier ein einzelner Host direkt angegeben |
| -m ping | Das Modul ping wird verwendet |
Von der Shell ins Playbook
Wird eine Aufgabe häufiger gebraucht, ist das Playbook die nächste Stufe. Beispiel:
– hosts: all:!testsystemkunde
become: true
tasks:
– name: DNS konfigurieren
copy:
content: |
search domain.de
nameserver 192.168.1.1
nameserver 192.168.1.2
options single-request-reopen
dest: /etc/resolv.conf
when: ansible_distribution in [„Ubuntu“, „Debian“, „CentOS“, „Fedora“]
Hier wird auf Systemen die das Betriebssystem Ubuntu, Debian, CentOs oder Fedora benutzen sichergestellt, dass die DNS Server 192.168.1.1 und 192.168.1.2 in der Datei /etc/resulv.conf eingetragen sind. Zusammen mit ein paar anderen Parametern.
Ein Playbook dokumentiert nicht nur was passiert – es ist die Dokumentation. Und wenn daraus Rollen entstehen, wird aus einem Shell-Befehl eine wiederverwendbare Infrastrukturbaustein.