Zum Inhalt

ADR-006: Bash-Provisioning statt Terraform/Ansible

Feld Wert
Status accepted
Datum 2026-03-21
Betrifft homelab-external, novabrands, claude-pi

Kontext

Drei Projekte muessen von einer Bare-Metal- oder vServer-Grundinstallation zu einem lauffaehigen Docker-Host provisioniert werden: homelab-external (Hetzner CX23), novabrands (OVH RISE-S) und claude-pi (Raspberry Pi 4B). Der Umfang umfasst Paketinstallation, SSH-Hardening, Firewall, Docker-Setup und Service-Deployment.

Alle drei Umgebungen sind Einzelserver ohne Cluster-Anforderungen. Der Betreiber ist eine einzelne Person mit Zugriff auf alle Maschinen.

Entscheidung

Provisioning erfolgt ueber Bash-Skripte (bootstrap.sh / setup.sh) mit set -euo pipefail. Die Skripte sind idempotent aufgebaut und benoetigen keine externen Abhaengigkeiten ausser Standardtools (curl, apt, systemctl).

Jedes Projekt enthaelt ein einzelnes Einstiegsskript, das alle Schritte von der Grundkonfiguration bis zum Service-Start sequenziell ausfuehrt.

Alternativen

Option Ergebnis
Terraform Deklarativer IaC-Ansatz mit State Management. Stark bei Cloud-Ressourcen (VMs, DNS, LBs), aber Overhead fuer die wenigen Ressourcen im Homelab. State-File muss gesichert werden, Provider-Versionen gepflegt.
Ansible Agentless Config Management mit Idempotenz. Guter Ansatz fuer mehrere identische Server, aber Overkill fuer drei unterschiedliche Einzelserver. Python-Abhaengigkeit, Inventory-Pflege, Lernkurve fuer Rollen-Struktur.
cloud-init Native Cloud-Initialisierung, laeuft nur beim ersten Boot. Keine Idempotenz, kein nachtraegliches Re-Provisioning moeglich. Nicht verfuegbar auf Bare-Metal (Raspberry Pi, OVH).

Konsequenzen

Positiv:

  • Keine externen Abhaengigkeiten — funktioniert auf jeder Linux-Maschine
  • Einfach zu lesen und zu debuggen mit Standard-Shell-Wissen
  • Kein State-File, das gesichert oder synchronisiert werden muss
  • Direkte Integration mit Cloud-APIs (hcloud, Cloudflare) ueber CLI-Tools

Negativ:

  • Kein Dry-Run-Modus — Aenderungen muessen manuell geprueft werden
  • Drift-Erkennung nur durch erneutes Ausfuehren des Skripts
  • Fehlerbehandlung weniger ausdrucksstark als deklarative Tools
  • Automatisierte Tests fuer Shell-Skripte sind aufwaendig (shellcheck hilft)