Files
michaelschiemer/deployment/docs/guides/ansible-vs-bash-scripts.md
Michael Schiemer 36ef2a1e2c
Some checks failed
🚀 Build & Deploy Image / Determine Build Necessity (push) Failing after 10m14s
🚀 Build & Deploy Image / Build Runtime Base Image (push) Has been skipped
🚀 Build & Deploy Image / Build Docker Image (push) Has been skipped
🚀 Build & Deploy Image / Run Tests & Quality Checks (push) Has been skipped
🚀 Build & Deploy Image / Auto-deploy to Staging (push) Has been skipped
🚀 Build & Deploy Image / Auto-deploy to Production (push) Has been skipped
Security Vulnerability Scan / Check for Dependency Changes (push) Failing after 11m25s
Security Vulnerability Scan / Composer Security Audit (push) Has been cancelled
fix: Gitea Traefik routing and connection pool optimization
- Remove middleware reference from Gitea Traefik labels (caused routing issues)
- Optimize Gitea connection pool settings (MAX_IDLE_CONNS=30, authentication_timeout=180s)
- Add explicit service reference in Traefik labels
- Fix intermittent 504 timeouts by improving PostgreSQL connection handling

Fixes Gitea unreachability via git.michaelschiemer.de
2025-11-09 14:46:15 +01:00

5.0 KiB

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:

# 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.