# Ansible: Infrastruktur-Automatisierung ohne Agenten

TL;DR / Management Summary Ein manuell konfigurierter Server ist ein Risiko. Ansible ermöglicht es, Infrastruktur als Code (IaC) zu verwalten. Es benötigt keine Agenten auf den Zielsystemen (nur SSH und Python) und nutzt eine menschenlesbare YAML-Syntax. Mit Ansible stellen wir sicher, dass 100 Server identisch konfiguriert sind, Sicherheits-Updates gleichzeitig erhalten und neue Instanzen in Minuten statt Stunden bereitstehen.

# 1. Einführung & Architektur

Agentless und Deklarativ.

Ansible folgt dem Push-Prinzip. Der Admin-Rechner (Control Node) sendet Befehle via SSH an die Zielserver (Managed Nodes).

graph TD
    A[Control Node: Ansible] -->|SSH Port 22| B[Server 1]
    A -->|SSH Port 22| C[Server 2]
    A -->|SSH Port 22| D[Server 3]
    subgraph "Files on Control Node"
        E[Inventory: List of IPs]
        F[Playbooks: Desired State]
        G[Roles: Reusable Tasks]
    end
    E --- A
    F --- A
    G --- A

# 2. Erste Schritte

Vom Inventory zum Ping.

# Installation

sudo apt update
sudo apt install ansible

# Das Inventory (hosts.ini)

Definieren Sie Ihre Server-Gruppen.

[webservers]
web01.company.com
web02.company.com

[dbservers]
db01.company.com

# Der erste Test

ansible all -m ping

# 3. Playbooks: Den Zielzustand beschreiben

Automatisierung in Aktion.

Ein Playbook beschreibt, wie ein System aussehen soll.

# Beispiel: Server Hardening (site.yml)

- name: Basic Server Hardening
  hosts: all
  become: yes
  tasks:
    - name: Ensure UFW is installed
      apt:
        name: ufw
        state: present

    - name: Allow SSH traffic
      ufw:
        rule: allow
        port: '22'
        proto: tcp

    - name: Install security updates
      apt:
        upgrade: dist
        update_cache: yes

    - name: Ensure sysadmin user exists
      user:
        name: sysadmin
        shell: /bin/bash
        groups: sudo

# 4. Day-2 Operations: Rollen & Galaxy

Wiederverwendbarkeit.

# Ansible Roles

Lagern Sie Aufgaben in Rollen aus (z.B. eine Rolle für Nginx, eine für PostgreSQL). Struktur: roles/nginx/tasks/main.yml.

# Ansible Galaxy

Nutzen Sie fertige Rollen der Community für Standardaufgaben (z.B. Docker-Install).

ansible-galaxy install geerlingguy.docker

# 5. Troubleshooting & “War Stories”

Wenn die Automatisierung hakt.

# Story 1: “Der SSH-Timeout”

Symptom: Ansible bricht bei 50% der Server mit “Unreachable” ab. Ursache: Zu viele parallele SSH-Verbindungen überlasten den Control-Node oder die Firewall des Zielnetzes. Lösung: Nutzen Sie das Flag forks in der ansible.cfg (z.B. forks = 10) oder nutzen Sie Ansible Mitogen für schnellere Verbindungen.

# Story 2: “Nicht-idempotente Skripte”

Symptom: Das Playbook meldet bei jedem Durchlauf “Changed”, auch wenn sich nichts geändert hat. Ursache: Nutzung des shell oder command Moduls ohne creates oder removes Bedingung. Lösung: Nutzen Sie immer native Ansible-Module (z.B. apt, template, file). Nur wenn es kein Modul gibt, nutzen Sie shell und fügen Sie eine Logik hinzu, die prüft, ob die Arbeit bereits getan ist.

# 6. Fazit & Empfehlung

• Idempotenz: Das wichtigste Konzept. Ein Playbook muss 10x ausgeführt werden können und das Ergebnis ist immer gleich.
• Versionierung: Playbooks gehören in Git!
• Secrets: Nutzen Sie Ansible Vault, um Passwörter in Playbooks zu verschlüsseln. ansible-vault encrypt vars/secrets.yml

# Anhang: Cheatsheet