Als ich Docker besser verstanden hatte, dachte ich zunächst, dass ich damit schon einen großen Teil moderner Infrastruktur abgedeckt hätte. Container starten, Images bauen, Volumes verwalten und mehrere Dienste mit Compose verbinden – das fühlte sich bereits ziemlich mächtig an.
Doch sobald mehr als ein Server ins Spiel kommt, beginnt das nächste Problem. Einstellungen müssen wiederholt, Systeme aktualisiert und Konfigurationen konsistent gehalten werden.
Genau an diesem Punkt wurde Infrastruktur-Automatisierung für mich interessant.
Manuelle Konfiguration funktioniert nur bis zu einem gewissen Punkt
Einen einzelnen Server kann man problemlos von Hand einrichten.
Bei fünf oder zehn Systemen sieht es schon anders aus. Wenn jeder Server leicht unterschiedlich konfiguriert ist, entstehen mit der Zeit Fehler und schwer nachvollziehbare Unterschiede.
Typische Aufgaben wiederholen sich ständig:
- Benutzer anlegen,
- Pakete installieren,
- Dienste konfigurieren,
- SSH-Einstellungen ändern,
- Firewalls setzen,
- Konfigurationsdateien verteilen.
Irgendwann stellte ich mir die Frage, warum ich all das immer wieder manuell machen sollte.
Ansible war für mich ein guter Einstieg
Ich bin deshalb auf Ansible gestoßen.
Der große Vorteil war für mich, dass ich nicht sofort eine komplizierte zusätzliche Infrastruktur brauchte. Viele Aufgaben lassen sich über SSH automatisieren und in gut lesbaren Playbooks beschreiben.
Ich habe zunächst ganz einfache Dinge ausprobiert:
- Pakete installieren,
- Dateien kopieren,
- Dienste starten,
- Benutzer verwalten,
- Konfigurationen ausrollen.
Später habe ich mich auf Dargslan genauer mit Ansible Automation beschäftigt. Dort geht es von einfachen Playbooks bis zu Rollen, Secrets, Tests und CI/CD-Integration.
Der wichtigste Gedanke war Wiederholbarkeit
Früher konnte ich einen Server konfigurieren und wusste danach oft nicht mehr genau, welche Schritte ich durchgeführt hatte.
Mit Automation ändert sich das.
Die Konfiguration wird dokumentiert und ausführbar.
Wenn ein neuer Server benötigt wird, kann derselbe Ablauf wiederverwendet werden. Änderungen lassen sich nachvollziehen, und die Wahrscheinlichkeit kleiner manueller Fehler sinkt deutlich.
Das war für mich eigentlich der größte Vorteil.
Nicht Geschwindigkeit allein, sondern Konsistenz.
Danach wurde Infrastructure as Code interessant
Je mehr ich mich mit Automatisierung beschäftigt habe, desto häufiger tauchte Terraform auf.
Dabei ging es nicht mehr nur darum, einen bereits vorhandenen Server zu konfigurieren. Stattdessen kann Infrastruktur selbst deklarativ beschrieben und erstellt werden.
Zum Beispiel:
- virtuelle Maschinen,
- Netzwerke,
- Subnetze,
- Security Groups,
- Load Balancer,
- Cloud-Ressourcen.
Das war zunächst ein ungewohnter Gedanke.
Infrastruktur nicht mehr per Klick in einer Weboberfläche zusammenbauen, sondern als Code behandeln.
Warum das gut zu Cloud und DevOps passt
Cloud-Umgebungen ändern sich häufig.
Neue Testsysteme werden aufgebaut, Ressourcen entfernt oder komplette Umgebungen für Entwicklung und Produktion benötigt.
Manuell würde das schnell unübersichtlich.
Genau deshalb gehören Terraform, Ansible und ähnliche Werkzeuge heute so eng zu DevOps. Die DevOps- und Infrastruktur-Ressourcen auf Dargslan verbinden diese Themen mit Docker, Kubernetes, CI/CD und Cloud-Technologien.
Für mich wurde dadurch auch klar, dass Automatisierung kein einzelnes Tool ist.
Es ist eher eine Arbeitsweise.
Ich habe mit kleinen Aufgaben begonnen
Der Fehler wäre gewesen, sofort eine komplette Produktionsumgebung automatisieren zu wollen.
Stattdessen habe ich kleine Ziele gewählt.
Zum Beispiel:
- einen Benutzer automatisch anlegen,
- einen Webserver installieren,
- eine Konfigurationsdatei verteilen,
- den Dienst starten,
- prüfen, ob er wirklich läuft.
Erst wenn dieser Ablauf zuverlässig funktioniert, lohnt es sich, größere Projekte daraus zu bauen.
Das hat mir geholfen, die Logik besser zu verstehen.
Gute Automation sollte auch mehrfach funktionieren
Ein Begriff, der mir dabei immer wieder begegnete, war Idempotenz.
Vereinfacht bedeutet das: Eine Automation sollte möglichst auch beim zweiten oder zehnten Lauf denselben gewünschten Zustand herstellen, ohne unnötig Dinge kaputtzumachen oder doppelt anzulegen.
Das klingt theoretisch, ist aber im Alltag extrem wichtig.
Ein Playbook, das nur einmal funktioniert und danach Fehler produziert, ist keine besonders gute Automation.
Heute sehe ich Infrastruktur anders
Früher bestand ein Server für mich hauptsächlich aus einem System, das ich per SSH betrete und dann manuell konfiguriere.
Heute denke ich viel stärker in reproduzierbaren Zuständen.
Welche Konfiguration soll vorhanden sein?
Wie kann ich sie automatisiert herstellen?
Wie dokumentiere ich sie so, dass sie später wiederverwendbar ist?
Genau dabei hat mir die Beschäftigung mit DevOps und Infrastructure as Code geholfen. Die Dargslan Topic Guides waren für mich ein guter Ausgangspunkt, weil dort Automatisierung nicht isoliert behandelt wird, sondern mit Cloud, Containern und Systemadministration zusammengeführt wird.
Das ist für mich mittlerweile der wichtigste Punkt.
Nicht möglichst viele Tools auswendig zu lernen, sondern zu verstehen, welches Problem ein Werkzeug löst und wie es in eine größere Infrastruktur passt.
Források
- Introduction to Ansible – Ansible Documentation (docs.ansible.com)
- Ansible Playbooks – Desired State and Idempotency (docs.ansible.com)
- Installing Ansible – Ansible Documentation (docs.ansible.com)
