Infrastructure as Code – Server als Nutzvieh

„Treat your servers like cattle, not pets.“ – Bill Baker / Randy Bias

Ziel dieses Bereichs: Linux-Server so zu betreiben, dass jede Instanz jederzeit aus Code reproduzierbar, austauschbar und ohne manuelle Eingriffe orchestrierbar ist.

Pets vs. Cattle

Aspekt Haustier (Pet) Nutzvieh (Cattle)
Name zeus, apollo web-prod-017
Entstehung Handinstallation, gewachsen Aus Image + Code, reproduzierbar
Konfiguration SSH, vi, „kurz mal eben“ Nur über Git und Pipeline
Bei Defekt Debuggen, pflegen, retten Wegwerfen, neu ausrollen
Dokumentation Wiki, Kopf des Admins Der Code ist die Dokumentation
Skalierung Größere Maschine (vertikal) Mehr Instanzen (horizontal)
Risiko Snowflake, Configuration Drift Identische, testbare Instanzen

Reifegradmodell

Stufe Bezeichnung Merkmal Werkzeuge
0 Manuell Klickanleitungen, SSH-Handarbeit –
1 Skriptbasiert Bash-Skripte, nicht idempotent Bash
2 Configuration Management Soll-Zustand deklariert, idempotent Ansible
3 Infrastructure as Code Auch VMs, Netze, DNS aus Code Terraform, Packer
4 Immutable & GitOps Kein SSH in Prod, Änderung = Neubau via Pipeline CI/CD, Policy as Code

Die Toolchain

 Git-Repo ──► CI/CD-Pipeline
                │
   ┌────────────┼──────────────┬──────────────────┐
   ▼            ▼              ▼                  ▼
 Packer     Terraform      cloud-init          Ansible
 (Image)    (Ressourcen)   (Bootstrap)         (Konfiguration)
   │            │              │                  │
   └──► Golden Image ──► VM/Instanz ──► erster Start ──► Soll-Zustand

Grundregeln

  1. Jede Änderung beginnt als Commit, nie auf dem Server.
  2. Kein Server ist unersetzlich; Daten liegen getrennt von der Instanz.
  3. Idempotenz: Jeder Lauf führt zum selben Ergebnis.
  4. Drift wird erkannt (terraform plan, Ansible –check) und durch Neubau beseitigt.
  5. Secrets gehören nie ins Repository.

Weiterführend