5 Architektur

5.1 Grundlagen einer agentenlosen Automatisierungsplattform

Ansible unterscheidet sich fundamental von traditionellen Automatisierungslösungen durch seine agentenlose Push-Architektur. Im Gegensatz zu Master-Agent-Systemen wie Puppet oder Chef benötigt Ansible keine persistente Serverkomponente auf den verwalteten Systemen.

Traditionelle Systeme: Agent-Dienste auf jedem System → kontinuierliche Master-Server-Kommunikation → zusätzliche Installation, Konfiguration, Updates und Überwachung erforderlich

Ansible-Ansatz: Direkte Kommunikation über SSH/WinRM → keine dauerhaften Prozesse → eliminiert Software-Schichten und reduziert Wartungsaufwände, Sicherheitsrisiken und Ausfallpunkte

5.2 Kernkomponenten im Überblick

5.2.1 Der Steuerknoten (Control Node)

Funktion: Zentrale Komponente zur Steuerung aller Ansible-Operationen

Technische Anforderungen:

Linux-System (CentOS, Ubuntu, RHEL) - Windows nicht unterstützt
Python 3.8+ (standardmäßig in modernen Distributionen)
SSH-Zugang zu Linux/Unix-Systemen
WinRM-Zugang zu Windows-Systemen
Ressourcen: 2 GB RAM für hunderte Server, skaliert entsprechend der Umgebungsgröße

5.2.2 Zielknoten (Managed Nodes)

Unterstützte Systeme: Physische Server, VMs, Container, Netzwerkgeräte, Cloud-Services

Minimale Anforderungen:

Linux/Unix: SSH-Zugang, Python (meist vorhanden, sonst automatisch installierbar)
Windows: WinRM-Zugang
Berechtigungen: Root-Rechte (Linux) oder Administrator-Rechte (Windows) für Systemkonfigurationen
Wichtig: Keine Ansible-Installation auf Zielknoten erforderlich

5.3 Das Inventar: Organisationsstruktur

5.3.1 Formate und Einsatzgebiete

Format	Anwendungsfall	Vorteile
INI	Einfache, statische Umgebungen	Leicht verständliche Syntax
YAML	Komplexe Hierarchien	Bessere Struktur und Lesbarkeit
Script/Plugin	Dynamische Umgebungen	Automatischer Bezug aus Cloud/CMDB

5.3.2 Bewährte Strukturierung

inventory/
├── hosts.yml                 # Haupt-Inventar
├── group_vars/
│   ├── all.yml              # Globale Variablen
│   ├── webservers.yml       # Webserver-Gruppe
│   └── databases.yml        # Datenbank-Gruppe
└── host_vars/
    ├── web01.example.com.yml # Host-spezifische Variablen
    └── db01.example.com.yml

Praktische Tipps:

Nutzen Sie Ranges für gleichartige Systeme: web[01:10].example.com
Implementieren Sie Gruppenhierarchien mit Vererbung
Verwenden Sie host_vars/ und group_vars/ für bessere Organisation

5.4 Playbooks und Module: Das Automatisierungsherz

5.4.1 Playbooks: Deklarative Konfiguration

Playbooks definieren WAS erreicht werden soll (nicht WIE). Ansible ermittelt automatisch die notwendigen Schritte zum gewünschten Zustand.

Struktur: YAML-basierte Orchestrierung von Tasks → jeder Task nutzt spezifische Module → Handler reagieren auf Änderungen

5.4.2 Module: Ausführende Einheiten

Funktionsweise:

Python-Programme werden zur Laufzeit vom Steuerknoten übertragen
Ausführung auf Zielknoten
Automatische Entfernung nach Abschluss

Vorteile: Keine permanenten Spuren, breite Funktionalität von Dateiverwaltung bis Cloud-Orchestrierung

5.5 Plugin-System: Gezielte Erweiterungen

5.5.1 Wichtigste Plugin-Typen

Plugin-Typ	Zweck	Beispiele	Anwendung
Connection	Kommunikationswege	`ssh`, `winrm`, `local`	Verschiedene Betriebssysteme
Inventory	Dynamische Systemlisten	`aws_ec2`, `azure_rm`, `gcp_compute`	Cloud-Integration
Lookup	Externe Datenquellen	`env`, `file`, `url`, `dig`	API-Calls, Umgebungsvariablen
Filter	Datenmanipulation	`to_json`, `select`, `map`	Template-Verarbeitung
Callback	Ausgabesteuerung	`minimal`, `json`, `profile_tasks`	Logging, Monitoring

5.6 CLI-Werkzeuge: Kommandozeilen-Interface

5.6.1 Kern-Kommandos (täglich genutzt)

Kommando	Funktion	Primärer Einsatz
`ansible-playbook`	Playbook-Ausführung	Hauptwerkzeug für Automatisierung
`ansible`	Ad-hoc-Kommandos	Schnelle Überprüfungen
`ansible-inventory`	Inventar-Analyse	Systemübersicht und Validierung

5.6.2 Erweiterte Werkzeuge (situativ)

Kommando	Funktion	Wann verwenden
`ansible-galaxy`	Rollen/Collections-Management	Community-Inhalte installieren
`ansible-vault`	Verschlüsselung	Sichere Daten verwalten
`ansible-doc`	Dokumentation	Module/Plugin-Hilfe
`ansible-config`	Konfiguration	Setup-Validierung

5.7 Execution Flow: Ablauf der Playbook-Ausführung

Phase	Hauptaufgaben
Parsing-Phase	YAML-Syntax-Validierung Playbook-Struktur-Analyse Include/Import-Auflösung
Inventory-Auflösung	Zielknoten-Identifikation Variable-Zusammenführung (Precedence-Regeln) Gruppierung und Limits
Task-Ausführung	Verbindungsaufbau zu Zielknoten Modul-Übertragung Parameter-Interpolation Remote-Ausführung
Result-Capture & Cleanup	Rückgabewerte sammeln Status-Aggregation Callback-Plugin-Benachrichtigung Temporäre Dateien entfernen

5.8 Collections: Community-Funktionspakete

Konzept: Thematisch zusammengehörige Module, Plugins und Rollen in versionierten Paketen

Vorteile:

Unabhängige Versionierung von Ansible-Kern
Reduzierte Kerninstallationsgröße
Community-getriebene Spezialisierung
Organisationsspezifische Standardisierung

5.9 Skalierung und Performance-Optimierung

5.9.1 Herausforderung agentenloser Architektur

Jeder Task benötigt neue Verbindung → potenzielle Performance-Engpässe in großen Umgebungen

5.9.2 Bewährte Optimierungsstrategien

Technik	Wirkung	Kombinierbar mit
Pipelining	Reduziert SSH-Verbindungen	ControlPersist, Parallelisierung
ControlPersist	Wiederverwendung von SSH-Verbindungen	Pipelining, Fact-Caching
Fact-Caching	Vermeidet wiederholtes Sammeln von Systeminformationen	Alle anderen Techniken
Parallelisierung	Gleichzeitige Ausführung auf mehreren Systemen	Pipelining, ControlPersist

Praxis-Tipp: Kombinieren Sie mehrere Techniken für optimale Performance:

# ansible.cfg
[defaults]
host_key_checking = False
pipelining = True
fact_caching = memory
fact_caching_timeout = 3600

[ssh_connection]
ssh_args = -o ControlMaster=auto -o ControlPersist=60s

5.10 Sicherheitsaspekte

5.10.1 Architektur-Vorteile

Reduzierte Angriffsfläche: Keine permanenten Agent-Prozesse
Automatische Bereinigung: Module werden nach Ausführung entfernt
Bewährte Protokolle: SSH/WinRM mit etablierter Sicherheitsinfrastruktur

5.10.2 Best-Practice-Sicherheit

SSH-Härtung:

# /etc/ssh/sshd_config
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
Protocol 2

Ansible-Vault-Strategien:

Separate Vault-Dateien für verschiedene Umgebungen
Rollenbasierte Vault-Passwörter
Integration mit externen Schlüsselmanagement-Systemen

Berechtigungsmanagement:

Dedizierte Ansible-Benutzer mit minimalen Rechten
Sudo-Konfiguration für spezifische Tasks
Regelmäßige Audit-Trails

5.11 Architekturvorteile in der Praxis

5.11.1 Einfachheit trifft Mächtigkeit

Niedrige Einstiegshürde: Minimale Infrastrukturanforderungen
Hohe Skalierbarkeit: Von kleinen Teams bis Enterprise-Umgebungen
Flexibilität: Von Konfigurationsmanagement bis Multi-Cloud-Orchestrierung

Die durchdachte Balance zwischen Einfachheit und Funktionalität macht Ansible zu einem wertvollen Werkzeug für moderne IT-Operationen. Die agentenlose Architektur reduziert nicht nur Komplexität, sondern ermöglicht auch Automatisierung für Organisationen jeder Größe, ohne Kompromisse bei Transparenz oder Erweiterbarkeit einzugehen.