Einleitung
Die Art und Weise, wie IT-Infrastruktur bereitgestellt und betrieben wird, hat sich in den vergangenen Jahrzehnten stark verändert. In den frühen Jahren der Systemadministration bestand der Alltag daraus, einzelne Server manuell zu installieren, Softwarepakete einzuspielen, Konfigurationen direkt in Dateien zu editieren und Dienste zu starten. Das war nicht nur zeitaufwändig, sondern auch fehleranfällig und schwer zu reproduzieren. Schon ein kleiner Unterschied in einer Konfiguration konnte zu Problemen führen, die sich kaum nachverfolgen ließen.
Mit der zunehmenden Digitalisierung, Virtualisierung und später Cloud-Technologien stiegen die Anforderungen an IT-Umgebungen enorm. Unternehmen brauchten plötzlich nicht mehr nur einzelne Server, sondern ganze Landschaften aus Dutzenden oder Hunderten Systemen, die konsistent und schnell bereitgestellt werden mussten. Gleichzeitig entstanden neue Anforderungen an Nachvollziehbarkeit, Compliance und Automatisierung. An dieser Stelle setzte sich das Konzept Infrastructure as Code (IaC) durch.
Die Grundidee von IaC ist so simpel wie mächtig: Infrastruktur wird nicht mehr manuell aufgebaut, sondern als Code beschrieben. Dieser Code legt den gewünschten Soll-Zustand einer Umgebung fest und sorgt dafür, dass er automatisiert erreicht wird. Damit wird Infrastruktur genauso behandelt wie Software: Sie ist versionierbar, überprüfbar, testbar und automatisierbar.
Besonders interessant wird IaC in Kombination mit modernen Werkzeugen wie Ansible und Plattformen wie GitLab. Ansible erlaubt es, Server- und Applikationsumgebungen mit klar lesbaren YAML-Playbooks zu beschreiben und zuverlässig zu konfigurieren. GitLab ergänzt diese Arbeitsweise um die Prinzipien der Softwareentwicklung: Versionskontrolle, Code-Reviews und CI/CD-Pipelines. So entsteht ein vollständiger Workflow: Von der Beschreibung der Infrastruktur über die Automatisierung bis hin zum kontrollierten Rollout in produktiven Umgebungen.
In diesem Artikel werfen wir zunächst einen Blick auf die Philosophie von IaC, gehen dann in die Geschichte des Ansatzes und zeigen schließlich anhand eines fortgeschrittenen Ansible-Beispiels, wie IaC praktisch umgesetzt wird. Den Abschluss bildet die Integration in GitLab CI/CD, um die Methoden aus der Softwareentwicklung konsequent auch für Infrastruktur einzusetzen.
Die Geschichte von IaC
Die Idee von Infrastructure as Code reicht weit zurück. Bereits 1993 führte CFEngine das Prinzip der Konvergenz ein: Systeme bewegen sich automatisch zu einem definierten Sollzustand. Mit Puppet (2005) und Chef (2009) wurden diese Ansätze massentauglich – erstmals konnten große Rechenzentren deklarativ und konsistent verwaltet werden.
2012 brachte Ansible den entscheidenden Schritt zur Vereinfachung: agentenlos, leicht lesbar in YAML und dadurch auch für kleinere Teams attraktiv. Kurz darauf entstand mit Terraform ein Tool, das den Fokus von reiner Konfiguration auf Provisionierung erweiterte und Cloud-Ressourcen plattformübergreifend per Code verwaltbar machte.
Heute ist IaC untrennbar mit DevOps und CI/CD verbunden: Plattformen wie GitLab sorgen dafür, dass Infrastruktur-Code versioniert, überprüft und automatisiert ausgerollt wird. Damit zeigt die Geschichte von IaC eine klare Linie: kein Trend, sondern eine konsequente Weiterentwicklung über Jahrzehnte – mit unverändert hoher Relevanz.
Die Philosophie von IaC
Infrastructure as Code ist weit mehr als ein technisches Werkzeug oder ein Automatisierungs-Framework. Es ist eine Denkweise, die den Umgang mit Infrastruktur grundlegend verändert. Während klassische Administration oft reaktiv war – „ein Problem tritt auf, also loggen wir uns ein und beheben es“ – verschiebt IaC den Schwerpunkt hin zu einem proaktiven, planbaren und überprüfbaren Modell.
1. Vom Handgriff zum Sollzustand
Im traditionellen Ansatz beschreibt ein Administrator Arbeitsschritte: „Installiere Paket X“, „Ändere Zeile Y in der Konfiguration“, „Starte Dienst Z neu“. IaC dagegen beschreibt Zustände: „Der Webserver ist installiert und läuft“, „Die Firewall erlaubt Port 80“. Damit tritt der Weg in den Hintergrund, und das Ziel rückt in den Mittelpunkt.
Diese Unterscheidung ist entscheidend: Skripte reproduzieren Befehle, IaC reproduziert Ergebnisse.
2. Wiederholbarkeit und Idempotenz
Ein zentrales Prinzip ist die Idempotenz. Wird ein IaC-Playbook mehrfach ausgeführt, entstehen keine unerwarteten Nebenwirkungen. Ansible-Module beispielsweise prüfen stets, ob ein gewünschter Zustand bereits erreicht ist, bevor sie eine Änderung durchführen. Das bedeutet: Infrastruktur „driftet“ nicht auseinander, sondern konvergiert immer wieder zum definierten Sollzustand.
3. Infrastruktur wird zu Code
Indem Infrastruktur in deklarativen Dateien beschrieben wird, wird sie Teil desselben Ökosystems wie Software:
- Änderungen liegen in Git-Repositories.
- Anpassungen werden über Merge Requests diskutiert.
- Qualität wird durch Tests und Pipelines sichergestellt.
Damit verschwindet die Trennlinie zwischen Entwicklern und Administratoren: Infrastruktur ist genauso versionierbar, überprüfbar und automatisierbar wie Anwendungs-Code.
4. Zusammenarbeit statt Inselwissen
Früher war es oft so: „Nur Admin X weiß, wie man den Server aufsetzt.“ Mit IaC verschwindet dieses Risiko. Der Code dient als lebende Dokumentation: Jeder im Team kann nachvollziehen, wie Systeme aufgebaut sind, und Änderungen sind transparent. Dadurch wird Wissen geteilt und nicht in Köpfen einzelner Personen versteckt.
5. Geschwindigkeit und Sicherheit schließen sich nicht aus
Ein oft gehörter Vorwurf lautet: „Automatisierung ist gefährlich, man verliert die Kontrolle.“ In Wahrheit ist das Gegenteil der Fall. Ohne IaC führt jede manuelle Änderung zu einer Abweichung, die nicht dokumentiert ist. Mit IaC dagegen ist jede Änderung sichtbar, prüfbar und im Zweifel auch rücksetzbar. Dadurch steigt nicht nur die Geschwindigkeit der Bereitstellung, sondern auch die Sicherheit und Nachvollziehbarkeit.
6. IaC als Teil des DevOps-Gedankens
IaC fügt sich nahtlos in die Ideen von DevOps ein. Entwickler und Administratoren sprechen über denselben Code, arbeiten im selben Repository und nutzen dieselben Prozesse. Ansible beschreibt den gewünschten Systemzustand, GitLab CI/CD sorgt für die automatisierte Ausführung, Tests und Überprüfungen. Infrastruktur wird so nicht mehr „nebenbei“ betrieben, sondern aktiv in Entwicklungs- und Delivery-Prozesse eingebunden.
Praxis: Ein Webserver mit Ansible
Playbook und Rollenstruktur
- name: Provisioniere Webserver mit Ansible
hosts: webserver
become: yes
roles:
- common
- nginx
Rolle common: Basispakete und Firewall-Regeln.
Rolle nginx: Installation, Konfiguration per Template, Handler zum Reload.
Beispiel Template:
server {
listen {{ nginx_listen_port }};
server_name {{ nginx_server_name }};
location / {
root /var/www/html;
index index.html;
}
}Philosophie in Aktion:
- Zustand statt Befehle: „Nginx läuft mit dieser Config“, nicht „führe apt-get aus“.
- Wiederholbar: Ein Host oder hundert – das Ergebnis ist gleich.
- Nachvollziehbar: Jede Änderung ist als Git-Diff sichtbar.
Von Code zur Pipeline: Ansible mit GitLab CI/CD
Ein Playbook im Repository ist wertvoll – richtig stark wird IaC aber erst dann, wenn Änderungen automatisiert überprüft und angewendet werden. GitLab bietet mit CI/CD dafür eine ideale Plattform. Der Grundgedanke: Jede Änderung an Infrastruktur-Code durchläuft denselben Lebenszyklus wie Software – Commit, Review, Tests und Deployment.
Beispiel .gitlab-ci.yml
stages:
- lint
- test
- deploy
ansible-lint:
stage: lint
image: cytopia/ansible-lint
script:
- ansible-lint playbooks/site.yml
ansible-dry-run:
stage: test
image: willhallonline/ansible:latest
script:
- ansible-playbook -i inventories/prod playbooks/site.yml --check --diff
deploy-prod:
stage: deploy
image: willhallonline/ansible:latest
script:
- ansible-playbook -i inventories/prod playbooks/site.yml
only:
- main
Erklärung
Linting (Qualitätssicherung)
In der ersten Stufe prüft ansible-lint, ob die Playbooks syntaktisch korrekt sind und gängige Best Practices einhalten. Fehler wie falsche Indents oder unsichere Module werden frühzeitig erkannt – bevor überhaupt etwas ausgerollt wird.
Dry-Run (Tests)
Mit --check --diff wird ein Probelauf gestartet. Dabei zeigt Ansible, welche Änderungen notwendig wären, ohne sie tatsächlich umzusetzen. Zusätzlich werden Unterschiede in Konfigurationsdateien angezeigt. So können Reviewer und Administratoren nachvollziehen, ob ein Merge die gewünschten Auswirkungen hat.
Deployment (Produktiv-Rollout)
Nur wenn alle Tests erfolgreich waren, wird im deploy-prod-Job das Playbook tatsächlich ausgeführt. GitLab sorgt dafür, dass dieser Schritt nur im main-Branch läuft – also nachdem die Änderung über Merge Request geprüft und freigegeben wurde. Damit werden versehentliche Schnellschüsse vermieden.
Warum GitLab + Ansible so gut zur IaC-Philosophie passen
- Versionskontrolle: Jede Änderung wird über Commits und Merge Requests dokumentiert.
- Transparenz: Pipelines laufen automatisch und zeigen klar, was wann wo passiert.
- Nachvollziehbarkeit: Linting, Dry-Runs und Diffs machen die Auswirkungen sichtbar, bevor etwas live geht.
- Sicherheit: Rollouts passieren nur nach Review und erfolgreicher Pipeline.
- Automatisierung: Infrastruktur wird wie Software behandelt – kein manuelles „Playbook anstoßen“ mehr.
Fazit
Infrastructure as Code hat eine lange Entwicklung hinter sich – von CFEngine über Puppet und Chef bis zu modernen Workflows mit Ansible und GitLab CI/CD. Neu ist der Ansatz nicht, doch relevanter denn je: Ohne IaC wäre es kaum möglich, komplexe und dynamische Infrastrukturen reproduzierbar, nachvollziehbar und sicher zu betreiben.
Ansible zeigt in der Praxis, wie die IaC-Philosophie umgesetzt wird: deklarativ, modular und idempotent. GitLab CI/CD erweitert diesen Ansatz um die Werkzeuge der Softwareentwicklung – Versionierung, Reviews, Tests und automatisierte Deployments. Zusammen entsteht ein durchgängiger Workflow, der sowohl Stabilität als auch Geschwindigkeit bringt.
Für viele Organisationen ist der Einstieg in IaC jedoch eine Herausforderung: Welche Tools passen zur bestehenden Umgebung? Wie baut man Playbooks und Rollen nachhaltig auf? Wie integriert man GitLab-Pipelines so, dass sie Prozesse sicher und reproduzierbar unterstützen? Und wie gelingt es, Teams auf diese neue Arbeitsweise vorzubereiten?
Genau hier kann NETWAYS helfen: mit Beratung bei der Tool-Auswahl, Best Practices für Architektur und Playbooks, Schulungen für Teams und Support bei Betrieb und Weiterentwicklung. Damit wird IaC nicht nur als Konzept verstanden, sondern auch im Alltag erfolgreich angewendet.
