Konfigurationsmanagement: Ansible Grundlagen

Konfigurationsmanagement: Ansible-Grundlagen

Diese Lektion ist eine Übersicht zu Ansible im Kontext von Software-Deployment. Du lernst die Grundkonzepte und siehst typische Anwendungsfälle – aber für die vollständige Vertiefung verweisen wir auf K55 L7, wo Inventory, Playbooks, Roles, Templates und Handlers im Detail behandelt werden.

recapDiese Lektion ist eine Kurzübersicht

Ansible ist ein vielschichtiges Tool, das in K55 (CI/CD) ausführlich behandelt wird, weil es im DevOps-Kontext extrem wichtig ist. Hier in K56 (Software Deployment) geht es vor allem darum, wie Ansible konkret für Software-Verteilung auf Linux- und Windows-Systemen genutzt wird. Die ausführliche Behandlung mit allen Konzepten findest du in 👉 K55 L7: Ansible Playbooks.

1) Was ist Ansible kurz gesagt?

Ansible ist Red Hats Open-Source-Tool für Configuration Management und Automatisierung. Du beschreibst in YAML-Dateien (sogenannten Playbooks) was auf deinen Servern sein soll – Pakete, Configs, Services – und Ansible setzt das automatisch um. Auf hunderten Servern gleichzeitig.

Die wichtigsten Eigenschaften:

Agentless: keine Software auf den Zielservern nötig, nur SSH und Python
Idempotent: mehrfach ausführen ist sicher – ändert nur was geändert werden muss
Deklarativ: du beschreibst den Soll-Zustand, nicht den Weg dorthin
YAML-basiert: gut lesbar, kein Programmieren nötig
Push-Modell: ein Control Node steuert viele Managed Nodes

2) Push-Modell: wie Ansible arbeitet

Anders als andere Tools (Puppet, Chef) braucht Ansible keinen Agent auf den Servern. Ein Control Node (z.B. dein Laptop oder ein CI-Server) verbindet sich per SSH zu den Managed Nodes:

Ansible Push-Architektur

🎯 Control Node

Wo Ansible installiert ist (Admin-Laptop, CI-Server)

↓ SSH-Verbindungen ↓

web01

Ubuntu

web02

Ubuntu

db01

RHEL

Du startest ansible-playbook auf dem Control Node. Ansible verbindet sich per SSH zu allen Managed Nodes parallel und führt die Tasks aus. Keine Agents, keine Master-Server, keine ständige Verbindung – nur wenn was passieren soll.

3) Zentrale Konzepte (Kurzversion)

Ansible hat eine eigene Begriffswelt. Hier die wichtigsten Begriffe in Kompaktform – die ausführliche Erklärung gibt's in K55 L7:

Ansible-Begriffe auf einen Blick

Inventory

Liste aller verwalteten Server, gruppiert

Playbook

YAML-Datei mit Tasks für eine Aufgabe

Task

Eine einzelne Aktion (Paket installieren, etc.)

Module

Plugin pro Task (apt, file, service, ...)

Role

Wiederverwendbare Sammlung von Tasks

Handler

Task der nur bei Änderungen läuft

Vars

Variablen für Tasks und Templates

Vault

Verschlüsselung für Secrets

Wenn dir einer dieser Begriffe unklar ist: K55 L7 Ansible Playbooks erklärt jeden im Detail mit Beispielen und Visualisierungen.

4) Ansible konkret im Deployment-Kontext

Wofür nutzen FISI und FIAE Ansible bei Software-Deployment? Konkrete Anwendungsfälle:

Server-Bereitstellung: neuer Server bekommt frische Linux-Installation, dann läuft Ansible-Playbook und installiert die ganze Software-Suite (Webserver, Datenbank, Monitoring-Agent)
App-Deployment: nach jedem Code-Push fährt Ansible los und installiert die neue Version auf allen App-Servern
Patch-Management: monatlich werden Sicherheitsupdates per Ansible auf alle Linux-Server gerollt
Konfig-Änderungen: zentrale Anpassung der Nginx-Config auf 50 Servern
User-Management: neuer Mitarbeiter braucht Accounts auf allen Servern
Software entfernen: alte Tools sauber von allen Geräten deinstallieren

5) Ein Playbook für Software-Deployment

Hier ein konkretes Beispiel: Nginx + PHP + MariaDB auf einer Server-Gruppe installieren. Selbst wenn du Ansible noch nicht kennst, wirst du erkennen was passiert – es ist sehr lesbar:

deploy-stack.ymlYAML

1- name: Deploy Web-Stack
hosts: webservers           # Welche Server?
become: true                # Mit sudo
4
tasks:
  - name: Pakete installieren
    apt:
      name: [nginx, php-fpm, mariadb-server]
      state: present
10
  - name: Nginx-Konfig kopieren
    template:
      src: nginx.conf.j2
      dest: /etc/nginx/sites-enabled/app
    notify: restart nginx
16
  - name: App-Code aus Git holen
    git:
      repo: https://github.com/firma/app.git
      dest: /var/www/app
      version: "{{ app_version }}"
22
  - name: Services starten
    service:
      name: "{{ item }}"
      state: started
      enabled: yes
    loop: [nginx, php-fpm, mariadb]
29
handlers:
  - name: restart nginx
    service: { name: nginx, state: restarted }

Vier Tasks: Pakete installieren, Nginx-Konfig kopieren, App-Code holen, Services starten. Plus ein Handler der Nginx neu startet, aber nur wenn die Konfig sich geändert hat. Genau so siehst du täglich Deployments im DevOps-Alltag.

6) Idempotenz: das Killer-Feature

Das wichtigste Konzept von Ansible: Idempotenz. Mehrfaches Ausführen ändert nichts mehr, wenn der Soll-Zustand erreicht ist. Beispiel:

Run 1: Nginx nicht installiert → wird installiert (CHANGED)
Run 2: Nginx schon da → nichts passiert (OK)
Run 3: Konfig wurde geändert → nur Nginx-Restart (CHANGED)

Diese Eigenschaft macht Ansible sicher: du kannst Playbooks beliebig oft laufen lassen, kein Schaden. Genau richtig für Deployments. Wenn ein Server ausfällt und neu aufgebaut wird – einfach das Playbook nochmal laufen lassen, Server ist wieder konfiguriert.

7) Typischer Deployment-Workflow mit Ansible

So sieht in der Praxis ein App-Deployment mit Ansible aus:

Praxis-Workflow: Software-Deployment via Ansible

Developer pusht Code in Git-Repo (Feature-Branch oder main)

CI-Pipeline baut Artefakt – Docker-Image, JAR, etc. Mehr in K55 L2

Pipeline triggert Ansible-Playbook – z.B. ansible-playbook deploy.yml -i staging

Ansible verbindet sich zu Servern per SSH (parallel)

Tasks laufen: Service stoppen, neue Version installieren, Konfig anpassen, DB-Migration, Service starten

Smoke-Test in der Pipeline: Health-Check auf allen Servern

Bei Erfolg: gleicher Ablauf für Production-Inventory

8) Ansible für Windows? Ja!

Ein Missverständnis: Ansible ist nicht nur für Linux. Es kann auch Windows-Server verwalten – via WinRM statt SSH. Das ist hilfreich in gemischten Umgebungen:

win-deploy.ymlYAML

1- name: Windows-Software installieren
hosts: windows_clients
tasks:
  - name: 7-Zip installieren
    win_chocolatey:
      name: 7zip
      state: present
8
  - name: MSI installieren
    win_package:
      path: \\share\setup.msi
      arguments: /quiet /norestart

Es gibt spezielle Windows-Module: win_chocolatey (für den Chocolatey-Paketmanager), win_package (für MSI/EXE), win_service, win_registry und viele mehr.

9) Vorteile gegenüber WSUS/Intune/PDQ

Wo punktet Ansible gegenüber den Windows-Tools aus L4?

Plattform-übergreifend: ein Tool für Linux, Windows, Network-Geräte, Cloud
Kostenlos: Open Source unter Apache-Lizenz
Versionierbar: Playbooks liegen in Git
Code-Reviews: Änderungen werden geprüft wie normaler Code
Reproduzierbar: gleicher Code → gleiches Ergebnis
Idempotent: mehrfach ausführen sicher

Nachteile gegenüber Intune: kein GUI (zumindest nicht ohne AWX/Tower), kein MDM für mobile Geräte, weniger Compliance-Reporting. Daher in der Praxis oft Kombination: Intune für Endpoints, Ansible für Server.

10) Wann Ansible wählen?

Konkrete Empfehlung wann Ansible das richtige Werkzeug ist:

Szenario	Ansible passt?
Linux-Server-Flotte verwalten	✓ Perfekt geeignet
Mixed Windows/Linux	✓ Funktioniert beides
App-Deployment in CI/CD	✓ Standard
Windows-Desktop-Geräte	⚠ Geht, aber Intune/PDQ einfacher
Mobile Devices (iOS/Android)	✗ Nutze Intune
Cloud-Provisioning (AWS, Azure)	⚠ Geht, aber Terraform besser für Infra
Konfig-Drift verhindern	✓ Stärke von Ansible
Ad-hoc-Tasks auf vielen Servern	✓ `ansible all -m shell -a "uptime"`

11) Was du als Nächstes lernen solltest

Wenn dich Ansible interessiert, sind die nächsten Schritte:

Lies K55 L7 Ansible Playbooks – ausführliche Behandlung aller Konzepte
Setze eine VM auf und installiere Ansible mit pip install ansible
Schreibe dein erstes Playbook – installiere Nginx auf einer Test-VM
Erkunde Ansible Galaxy – Marketplace mit fertigen Roles für viele Standard-Aufgaben
Integriere in CI/CD – Pipeline ruft Ansible am Ende auf
Lerne Terraform – beide ergänzen sich (Terraform für Infra, Ansible für Konfig)

Zusammenfassung

Ansible ist ein Open-Source-Tool für Configuration Management und Software-Deployment. Agentless (nur SSH + Python), idempotent (mehrfach ausführen sicher), deklarativ (YAML-Playbooks). Push-Modell: Control Node → Managed Nodes. Konzepte: Inventory, Playbook, Task, Module, Role, Handler, Vars, Vault. Im Deployment-Kontext typische Use Cases: Server-Bereitstellung, App-Deployment, Patch-Management, Konfig-Änderungen. Funktioniert auch für Windows via WinRM mit speziellen Modulen. Vorteile gegenüber WSUS/Intune: plattform-übergreifend, versionierbar, code-reviewbar. Diese Lektion ist nur eine Übersicht – für die ausführliche Behandlung mit allen Konzepten siehe 👉 K55 L7 Ansible Playbooks.