michaelschiemer/deployment/docs/guides/ansible-vs-bash-scripts.md

# Ansible vs. Bash-Scripts: Empfehlung

## Aktuelle Situation

### Bash-Scripts (Quick-Start)
- ✅ `deployment/scripts/staging-quick-start.sh`
- ✅ `deployment/scripts/production-quick-start.sh`
- **Zweck**: Schnelle, interaktive Tests und Verifikationen

### Ansible (Deployment)
- ✅ `deployment/ansible/playbooks/setup-staging.yml`
- ✅ `deployment/ansible/playbooks/setup-infrastructure.yml`
- ✅ `deployment/ansible/playbooks/backup.yml`
- **Zweck**: Strukturierte Deployments, Wartung, Automatisierung

## Vergleich

### Bash-Scripts

**Vorteile:**
- ✅ **Einfach**: Keine Dependencies, direkt ausführbar
- ✅ **Schnell**: Sofortige Ausführung, kein Setup nötig
- ✅ **Interaktiv**: Menü-basiert, benutzerfreundlich
- ✅ **Flexibel**: Einfache Anpassungen möglich
- ✅ **Debugging**: Einfach zu debuggen, direkte Ausgabe

**Nachteile:**
- ❌ **Nicht idempotent**: Mehrfache Ausführung kann Probleme verursachen
- ❌ **Wartung**: Schwerer zu warten bei komplexen Logiken
- ❌ **Fehlerbehandlung**: Manuelle Fehlerbehandlung nötig
- ❌ **Dokumentation**: Code als Dokumentation, weniger strukturiert
- ❌ **Wiederverwendbarkeit**: Schwerer in andere Kontexte zu integrieren

### Ansible

**Vorteile:**
- ✅ **Idempotent**: Mehrfache Ausführung sicher
- ✅ **Strukturiert**: Klare Rollen, Tasks, Variablen
- ✅ **Wartbar**: Einfacher zu erweitern und zu warten
- ✅ **Fehlerbehandlung**: Integrierte Retry-Logik, bessere Fehlermeldungen
- ✅ **Dokumentation**: Selbst-dokumentierend durch Tasks
- ✅ **Wiederverwendbar**: Tasks können in verschiedenen Playbooks genutzt werden
- ✅ **Konsistent**: Gleiche Tools wie für Deployment
- ✅ **Testing**: Ansible-Lint, Syntax-Checks, etc.

**Nachteile:**
- ❌ **Setup**: Ansible muss installiert sein
- ❌ **Komplexität**: Etwas komplexer für einfache Tasks
- ❌ **Interaktivität**: Weniger interaktiv (aber möglich mit `ansible-prompt`)

## Empfehlung: Hybrid-Ansatz

### Für was Bash-Scripts nutzen?

**Gut für:**
- ✅ **Schnelle Verifikationen**: Container-Status, Logs anzeigen
- ✅ **Interaktive Tests**: Menü-basierte Auswahl
- ✅ **Debugging**: Ad-hoc-Tasks während Problemlösung
- ✅ **Entwickler-Freundlich**: Keine Ansible-Kenntnisse nötig

**Beispiele:**
- Container-Status prüfen
- Logs anzeigen
- Health-Checks durchführen
- Netzwerk-Verbindungen testen

### Für was Ansible nutzen?

**Gut für:**
- ✅ **Deployments**: Strukturierte, wiederholbare Deployments
- ✅ **Setup**: Initiales Setup von Stacks
- ✅ **Wartung**: Regelmäßige Wartungsaufgaben
- ✅ **Backups**: Automatisierte Backup-Prozesse
- ✅ **CI/CD-Integration**: In Pipelines integrierbar

**Beispiele:**
- Stack-Deployment
- Konfiguration-Management
- Backup-Automatisierung
- System-Updates

## Langfristige Strategie

### Phase 1: Aktuell (Hybrid)
- **Bash-Scripts**: Für schnelle Verifikationen und interaktive Tests
- **Ansible**: Für Deployments und Wartung

### Phase 2: Erweiterung (Empfohlen)
- **Ansible-Playbooks erweitern**: Mehr Verifikations-Tasks
- **Bash-Scripts behalten**: Für interaktive, ad-hoc-Tasks

### Phase 3: Konsolidierung (Optional)
- **Ansible als primäres Tool**: Alle Tasks als Ansible-Playbooks
- **Bash-Scripts als Wrapper**: Dünne Wrapper um Ansible-Playbooks

## Konkrete Empfehlung

### Kurzfristig (Jetzt)
✅ **Beide behalten**:
- Bash-Scripts für schnelle, interaktive Tests
- Ansible für strukturierte Deployments

### Mittelfristig (3-6 Monate)
✅ **Ansible erweitern**:
- Verifikations-Playbooks erstellen
- Health-Check-Playbooks
- Monitoring-Playbooks

### Langfristig (6+ Monate)
✅ **Ansible als Standard**:
- Alle wiederholbaren Tasks als Ansible-Playbooks
- Bash-Scripts nur für sehr spezifische, einmalige Tasks

## Beispiel: Ansible-Verifikations-Playbook

Statt Bash-Script könnte man auch ein Ansible-Playbook erstellen:

```yaml
# deployment/ansible/playbooks/verify-staging.yml
---
- name: Verify Staging Environment
  hosts: production
  tasks:
    - name: Check PostgreSQL-Staging Stack
      community.docker.docker_compose_v2:
        project_src: "{{ postgresql_staging_stack_path }}"
        state: present
      register: postgresql_staging_status
    
    - name: Verify PostgreSQL-Staging Connection
      uri:
        url: "postgresql://postgres:{{ vault_db_password_staging }}@postgres-staging:5432/michaelschiemer_staging"
        method: GET
    
    - name: Check Staging Application Stack
      community.docker.docker_compose_v2:
        project_src: "{{ staging_stack_path }}"
        state: present
    
    - name: Health Check
      uri:
        url: "https://staging.michaelschiemer.de/health"
        method: GET
        status_code: [200]
```

**Vorteil**: Idempotent, strukturiert, in CI/CD integrierbar

## Fazit

**Aktuell**: Hybrid-Ansatz ist optimal
- Bash-Scripts für schnelle, interaktive Tests ✅
- Ansible für strukturierte Deployments ✅

**Langfristig**: Ansible ausbauen
- Mehr Verifikations-Playbooks
- Bash-Scripts nur für sehr spezifische Tasks
- Konsistente Tool-Nutzung

**Empfehlung**: Beide behalten, aber Ansible schrittweise erweitern für wiederholbare Tasks.