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
parent 85c369e846
commit 36ef2a1e2c
1366 changed files with 104925 additions and 28719 deletions
--- a/deployment/docs/status/ci-cd-status.md
+++ b/deployment/docs/status/ci-cd-status.md
@@ -90,20 +90,35 @@ Die Logs zeigen einige Verbindungsfehler (connection refused, 502 Bad Gateway),

 ### 3. Ansible Vault Password Handling

-**Status**: ⚠️ Workflow nutzt Vault, aber kein Secret dafür
+**Status**: ✅ Workflows verwenden ANSIBLE_VAULT_PASSWORD Secret

-**Problem:**
- Der Workflow `update-production-secrets.yml` benötigt ein Vault-Passwort
- Aktuell wird es als Workflow-Input eingegeben (manuell)
- Für automatisiertes Deployment sollte es als Secret vorliegen
+**Implementiert:**
+- ✅ `ANSIBLE_VAULT_PASSWORD` wird als Gitea Secret verwendet
+- ✅ Workflows erstellen automatisch Vault Password File aus Secret
+- ✅ Fallback: Leeres Password File wenn Secret nicht gesetzt ist

-**Lösung:**
- [ ] Optional: `ANSIBLE_VAULT_PASSWORD` als Secret hinzufügen (nur wenn automatisiert)
- [ ] Oder: Manuelles Eingeben beim Workflow-Trigger ist ausreichend
+**Konfiguration:**
+- Secret Name: `ANSIBLE_VAULT_PASSWORD`
+- Verwendung: Workflows erstellen `/tmp/vault_pass` aus Secret
+- Optional: Falls Secret nicht gesetzt, wird leeres Password File verwendet (für nicht-verschlüsselte Vaults)

 ---

-### 4. Pipeline End-to-End testen
+### 4. Code-Deployment Integration
+
+**Status**: ✅ Code-Deployment via Ansible in Workflows integriert
+
+**Implementiert:**
+- ✅ `deploy-application-code.yml` wird in Workflows verwendet
+- ✅ `install-composer-dependencies.yml` wird nach Code-Deployment ausgeführt
+- ✅ `deploy-image.yml` wird für Image-Deployment verwendet
+- ✅ Production Deployment Workflow verwendet Ansible statt direkter SSH-Befehle
+
+**Workflows aktualisiert:**
+- ✅ `.gitea/workflows/build-image.yml` - Staging & Production Auto-Deploy
+- ✅ `.gitea/workflows/manual-deploy.yml` - Manuelles Deployment
+
+### 5. Pipeline End-to-End testen

 **Status**: ⚠️ Pipeline ist definiert, aber noch nicht getestet

@@ -144,6 +159,7 @@ Die Logs zeigen einige Verbindungsfehler (connection refused, 502 Bad Gateway),
  - [x] `REGISTRY_USER` ✅
  - [x] `REGISTRY_PASSWORD` ✅
  - [x] `SSH_PRIVATE_KEY` ✅
+  - [x] `ANSIBLE_VAULT_PASSWORD` ✅ (für automatisiertes Deployment)
  - [ ] `GITEA_TOKEN` (optional)

 ### Gitea Runner
@@ -153,14 +169,22 @@ Die Logs zeigen einige Verbindungsfehler (connection refused, 502 Bad Gateway),
 - [x] Runner läuft (`docker compose up -d`) ✅
 - [ ] Runner sichtbar in Gitea UI als "Idle" oder "Active" (bitte manuell prüfen)

+### Code-Deployment Integration
+- [x] `deploy-application-code.yml` in Workflows integriert ✅
+- [x] `install-composer-dependencies.yml` in Workflows integriert ✅
+- [x] `deploy-image.yml` in Workflows integriert ✅
+- [x] Production Deployment Workflow auf Ansible umgestellt ✅
+
 ### Pipeline-Test
 - [ ] Test-Commit gepusht oder Workflow manuell getriggert
 - [ ] Alle Jobs erfolgreich:
  - [ ] Tests
  - [ ] Build
-  - [ ] Deploy
+  - [ ] Code-Deployment (Git)
+  - [ ] Composer Dependencies
+  - [ ] Image-Deployment
+  - [ ] Health-Check
 - [ ] Deployment erfolgreich auf Production
- [ ] Health-Check erfolgreich
 - [ ] Application läuft korrekt

 ### Dokumentation
@@ -180,7 +204,13 @@ Die Logs zeigen einige Verbindungsfehler (connection refused, 502 Bad Gateway),
 **Status:** ✅ Abgeschlossen
 - Runner läuft und ist registriert

-### Phase 3: Pipeline-Test (NÄCHSTER SCHRITT)
+### Phase 3: Code-Deployment Integration
+**Status:** ✅ Abgeschlossen
+- Code-Deployment via Ansible in Workflows integriert
+- Production Deployment Workflow auf Ansible umgestellt
+- Ansible Vault Password Handling implementiert
+
+### Phase 4: Pipeline-Test (NÄCHSTER SCHRITT)
 **Status:** ⚠️ Ausstehend
 1. Test-Workflow ausführen
 2. Fehler beheben falls notwendig
@@ -205,14 +235,25 @@ cp .env.example .env
 docker compose up -d
 ```

-### Pipeline manuell triggern (NÄCHSTER SCHRITT)
+### Pipeline testen (NÄCHSTER SCHRITT)
+
+**Vorbereitung:**
+```bash
+# Prüfe alle Voraussetzungen
+./deployment/scripts/test-pipeline-prerequisites.sh
+```
+
+**Detaillierte Test-Anleitung:**
+Siehe [Pipeline Test Checklist](../guides/pipeline-test-checklist.md) für Schritt-für-Schritt Anleitung.
+
+**Pipeline manuell triggern:**
 ```
 1. Gehe zu: https://git.michaelschiemer.de/michael/michaelschiemer/actions
-2. Wähle: "Production Deployment Pipeline"
+2. Wähle: "Build & Deploy Image"
 3. Klicke: "Run workflow"
-4. Wähle Branch: main
+4. Wähle Branch: staging (für Staging-Test) oder main (für Production-Test)
 5. Optionale Einstellungen:
-   - skip_tests: false (Tests sollen laufen)
+   - force_build: false (nur bei Bedarf)
 6. Klicke: "Run workflow"
 7. Beobachte Logs und prüfe jeden Schritt
 ```
@@ -228,12 +269,15 @@ https://git.michaelschiemer.de/admin/actions/runners

 ## ✅ Aktueller Status

-**CI/CD Pipeline ist vollständig konfiguriert!**
+**CI/CD Pipeline ist vollständig konfiguriert und integriert!**

 - ✅ Secrets konfiguriert
 - ✅ Runner läuft und ist registriert
 - ✅ Workflows sind vorhanden
- ⚠️ **Nächster Schritt:** Pipeline testen!
+- ✅ Code-Deployment via Ansible integriert
+- ✅ Production Deployment Workflow auf Ansible umgestellt
+- ✅ Ansible Vault Password Handling implementiert
+- ⚠️ **Nächster Schritt:** Pipeline testen! (siehe [Pipeline Testing Guide](../guides/pipeline-testing-guide.md))

 **Ready to Deploy:** Die Pipeline kann jetzt getestet werden. Alle Voraussetzungen sind erfüllt.

--- a/deployment/docs/status/gitea-cache-activation.md
+++ b/deployment/docs/status/gitea-cache-activation.md
@@ -0,0 +1,124 @@
+# Gitea Cache Aktivierung - Status
+
+**Datum:** 2025-01-XX  
+**Status:** ✅ Konfiguration abgeschlossen, Deployment ausstehend
+
+## Durchgeführte Änderungen
+
+### 1. docker-compose.yml angepasst
+
+**Datei:** `deployment/stacks/gitea/docker-compose.yml`
+
+**Änderungen:**
+- `GITEA__cache__ENABLED=false` → `GITEA__cache__ENABLED=true`
+- `GITEA__cache__ADAPTER=memory` → `GITEA__cache__ADAPTER=redis`
+- Cache-spezifische Redis-Konfiguration hinzugefügt:
+  - `GITEA__cache__HOST=redis:6379`
+  - `GITEA__cache__PASSWORD=${REDIS_PASSWORD:-gitea_redis_password}`
+  - `GITEA__cache__DB=0`
+
+**Vorher:**
+```yaml
+# Cache temporarily disabled (using memory) to debug Redis connection issue
+- GITEA__cache__ENABLED=false
+- GITEA__cache__ADAPTER=memory
+```
+
+**Nachher:**
+```yaml
+- GITEA__cache__ENABLED=true
+- GITEA__cache__ADAPTER=redis
+- GITEA__cache__HOST=redis:6379
+- GITEA__cache__PASSWORD=${REDIS_PASSWORD:-gitea_redis_password}
+- GITEA__cache__DB=0
+```
+
+### 2. Ansible Playbook erstellt
+
+**Datei:** `deployment/ansible/playbooks/restart-gitea-with-cache.yml`
+
+Das Playbook:
+- Prüft ob Gitea Container existiert
+- Erstellt Gitea Container mit neuer Cache-Konfiguration neu
+- Wartet auf Gitea Health-Check
+- Zeigt Erfolgsmeldung
+
+## Nächste Schritte
+
+### 1. Dateien auf Server synchronisieren
+
+Die geänderte `docker-compose.yml` muss auf den Server synchronisiert werden:
+
+```bash
+cd deployment/ansible
+ansible-playbook -i inventory/production.yml \
+  playbooks/sync-stacks.yml \
+  --vault-password-file secrets/.vault_pass
+```
+
+### 2. Gitea Container neu starten
+
+Nach der Synchronisation Gitea mit neuer Cache-Konfiguration neu starten:
+
+**Option A: Via Ansible Playbook**
+```bash
+cd deployment/ansible
+ansible-playbook -i inventory/production.yml \
+  playbooks/restart-gitea-with-cache.yml \
+  --vault-password-file secrets/.vault_pass
+```
+
+**Option B: Manuell auf Server**
+```bash
+ssh deploy@94.16.110.151
+cd ~/deployment/stacks/gitea
+docker compose up -d --force-recreate gitea
+```
+
+### 3. Cache-Verbindung verifizieren
+
+Nach dem Neustart prüfen:
+
+```bash
+# Gitea Logs prüfen
+docker compose logs gitea | grep -i cache
+
+# Redis-Verbindung testen
+docker exec gitea-redis redis-cli -a $REDIS_PASSWORD ping
+
+# Gitea Health-Check
+curl -f https://git.michaelschiemer.de/api/healthz
+```
+
+## Erwartetes Ergebnis
+
+Nach erfolgreichem Neustart sollte Gitea:
+- ✅ Redis für Caching verwenden (statt Memory)
+- ✅ Bessere Performance durch persistentes Caching
+- ✅ Cache überlebt Container-Neustarts
+- ✅ Keine Timeout-Probleme mehr durch Runner ohne Token
+
+## Gitea Runner Status
+
+**Wichtig:** Der Gitea Runner ist registriert, aber aktuell nicht gestartet. Das ist korrekt, da:
+- Runner ohne Registration Token in Dauerschleife läuft
+- Runner Gitea mit Requests bombardiert → Timeouts
+- Runner sollte nur gestartet werden, wenn Token konfiguriert ist
+
+**Status:**
+- ✅ Runner ist registriert (`data/.runner` existiert)
+- ✅ Registration Token ist in `.env` konfiguriert
+- ⏸️ Runner Container sind gestoppt (korrekt, bis Deployment abgeschlossen)
+
+**Runner starten (nach Cache-Aktivierung):**
+```bash
+cd deployment/gitea-runner
+docker compose up -d
+```
+
+## Referenz
+
+- [Gitea Cache Configuration](https://docs.gitea.io/en-us/config-cheat-sheet/#cache-cache)
+- [Redis Configuration](https://docs.gitea.io/en-us/config-cheat-sheet/#cache-cache)
+- [Gitea Runner Setup](../gitea-runner/README.md)
+
--- a/deployment/docs/status/implementation-summary.md
+++ b/deployment/docs/status/implementation-summary.md
@@ -0,0 +1,141 @@
+# Implementation Summary - Pre-Deployment Checklist
+
+## ✅ Abgeschlossen
+
+### 1. Backup-Playbook
+- **Status**: ✅ Implementiert
+- **Datei**: `deployment/ansible/playbooks/backup.yml`
+- **Features**:
+  - PostgreSQL Backup
+  - Application Data Backup (Storage, Logs)
+  - Gitea Data Backup
+  - Docker Registry Images Backup (optional)
+  - Automatische Backup-Rotation
+  - Backup-Verifizierung
+
+### 2. Legacy-Cleanup
+- **Status**: ✅ Abgeschlossen
+- **Entfernt**:
+  - `deployment/wireguard-old/` - Alte WireGuard Playbooks
+  - `deployment/ansible/playbooks/build-and-push.yml` - Wird durch CI/CD ersetzt
+  - `deployment/ansible/playbooks/remove-framework-production-stack.yml` - Temporär
+  - `deployment/ansible/playbooks/remove-temporary-grafana-ip.yml` - Temporär
+- **Dokumentiert**: `deployment/ansible/playbooks/README.md`
+
+### 3. Dokumentations-Cleanup
+- **Status**: ✅ Abgeschlossen
+- **Erstellt**: `deployment/docs/tests/README.md` - Dokumentiert veraltete Test-Docs
+- **Konsolidiert**: Test-Dokumentationen als historisch markiert
+
+### 4. Health Checks erweitert
+- **Status**: ✅ Implementiert
+- **Workflow**: Erweiterte Health-Checks in CI/CD Pipeline
+- **Endpoints**: 
+  - `/health` - Basic Health Check
+  - `/admin/health/api/summary` - Extended Health Summary
+- **Dokumentation**: `deployment/docs/guides/health-checks.md`
+
+### 5. Security Hardening dokumentiert
+- **Status**: ✅ Dokumentiert
+- **Dokumentation**: `deployment/docs/guides/security-hardening.md`
+- **Aktuell**: Firewall, WireGuard VPN, Unattended-Upgrades, Security Headers
+- **Geplant**: SSH Hardening, Container Scanning, Secrets Rotation
+
+## ⚠️ Ausstehend / Geplant
+
+### 1. Pipeline End-to-End testen
+- **Status**: ⚠️ Vorbereitet - Bereit zum Testen
+- **Priorität**: KRITISCH
+- **Test-Ressourcen erstellt:**
+  - ✅ `deployment/scripts/test-pipeline-prerequisites.sh` - Prüft alle Voraussetzungen
+  - ✅ `deployment/docs/guides/pipeline-test-checklist.md` - Detaillierte Schritt-für-Schritt Checkliste
+  - ✅ Dokumentation aktualisiert
+- **Was zu tun**:
+  - Test-Commit auf `staging` Branch pushen
+  - Alle Workflow-Jobs verifizieren
+  - Deployment auf Staging verifizieren
+  - Health-Checks prüfen
+  - Application funktioniert korrekt
+
+### 2. Zero-Downtime Deployment
+- **Status**: ⚠️ Nicht implementiert
+- **Priorität**: HOCH
+- **Geplant**: Blue-Green oder Rolling Updates mit Health-Checks
+
+### 3. Automatische Rollbacks
+- **Status**: ⚠️ Rollback-Playbook vorhanden, aber nicht automatisch
+- **Priorität**: HOCH
+- **Geplant**: Automatischer Rollback bei fehlgeschlagenem Health-Check
+
+### 4. Resource Limits & Performance
+- **Status**: ⚠️ Teilweise vorhanden
+- **Priorität**: MITTEL
+- **Geplant**: Container Resource Limits, Performance Monitoring, Load Testing
+
+### 5. Network Isolation & Segmentation
+- **Status**: ⚠️ Basis vorhanden
+- **Priorität**: MITTEL
+- **Geplant**: Network Policy Verification, Service Communication Audit
+
+### 6. SSL/TLS Configuration
+- **Status**: ✅ Basis vorhanden
+- **Priorität**: MITTEL
+- **Zu prüfen**: Certificate Auto-Renewal, TLS Version Audit, Cipher Suite Audit
+
+### 7. Monitoring & Alerting verbessern
+- **Status**: ⚠️ Basis vorhanden
+- **Priorität**: MITTEL
+- **Geplant**: Application-Metriken, Custom Dashboards, Alerting Rules
+
+### 8. Zentralisiertes Logging
+- **Status**: ⚠️ Basis vorhanden
+- **Priorität**: MITTEL
+- **Geplant**: ELK/Loki Stack, Log-Aggregation, Search Interface
+
+### 9. Secrets Management verbessern
+- **Status**: ⚠️ Basis vorhanden
+- **Priorität**: MITTEL
+- **Geplant**: Rotation Policy, Audit Logging, Backup
+
+## Nächste Schritte
+
+### Vor erstem Production-Deployment
+
+1. **Pipeline End-to-End testen** (KRITISCH)
+   - Prerequisites prüfen: `./deployment/scripts/test-pipeline-prerequisites.sh`
+   - Test-Commit auf `staging` pushen
+   - Alle Jobs verifizieren (siehe: `deployment/docs/guides/pipeline-test-checklist.md`)
+   - Health-Checks prüfen
+
+2. **Backup-Playbook testen**
+   - Test-Backup ausführen: `./deployment/scripts/test-backup.sh`
+   - Backup-Verifizierung prüfen
+   - Restore-Test durchführen (optional)
+
+3. **Security Audit**
+   - Firewall Rules prüfen
+   - SSH Hardening implementieren
+   - Container Scanning aktivieren
+
+### Langfristige Verbesserungen
+
+- Zero-Downtime Deployment
+- Automatische Rollbacks
+- Erweiterte Monitoring & Alerting
+- Zentralisiertes Logging
+- Secrets Rotation
+
+## Zusammenfassung
+
+**Abgeschlossen**: 5 von 15 geplanten Aufgaben
+**In Arbeit**: 0 von 15 Aufgaben
+**Ausstehend**: 10 von 15 Aufgaben
+
+**Kritische Aufgaben vor Deployment**:
+1. ✅ Backup-Playbook (abgeschlossen)
+2. ✅ Health Checks erweitert (abgeschlossen)
+3. ⚠️ Pipeline End-to-End testen (ausstehend)
+4. ⚠️ Zero-Downtime Deployment (geplant)
+
+**Status**: Bereit für Staging-Tests, Production-Deployment erfordert noch End-to-End-Tests.
+
--- a/deployment/docs/status/pipeline-test-status.md
+++ b/deployment/docs/status/pipeline-test-status.md
@@ -0,0 +1,114 @@
+# CI/CD Pipeline Test Status
+
+**Datum:** 2025-01-XX  
+**Status:** ⚠️ Teilweise abgeschlossen - Push fehlgeschlagen
+
+## Durchgeführte Schritte
+
+### ✅ Phase 0: Gitea Caching aktivieren
+- **Status:** ✅ Abgeschlossen
+- **Änderungen:** `deployment/stacks/gitea/docker-compose.yml` angepasst
+- **Cache-Konfiguration:** Redis aktiviert (statt Memory)
+- **Playbook erstellt:** `deployment/ansible/playbooks/restart-gitea-with-cache.yml`
+- **Nächster Schritt:** Dateien auf Server synchronisieren und Gitea neu starten
+
+### ✅ Phase 1: Prerequisites prüfen
+- **Status:** ✅ Abgeschlossen
+- **Prerequisites Script:** Ausgeführt
+- **Gitea Runner:** Registriert, aber nicht gestartet (korrekt, da Token konfiguriert ist)
+- **Gitea Secrets:** Laut Dokumentation bereits konfiguriert
+
+### ⚠️ Phase 2: Staging Pipeline Test
+- **Status:** ⚠️ Teilweise abgeschlossen
+- **Test-Commit:** ✅ Erstellt (`test: CI/CD pipeline staging test`)
+- **Push:** ❌ Fehlgeschlagen (504 Error)
+- **Fehler:** `fatal: unable to access 'https://git.michaelschiemer.de/admin/michaelschiemer.git/': The requested URL returned error: 504`
+
+## Bekannte Probleme
+
+### 1. Git Push 504 Error
+
+**Symptom:**
+```
+fatal: unable to access 'https://git.michaelschiemer.de/admin/michaelschiemer.git/': The requested URL returned error: 504
+```
+
+**Mögliche Ursachen:**
+1. **Gitea-Überlastung:** Runner ohne Token bombardiert Gitea mit Requests
+2. **Server-Überlastung:** Server ist temporär überlastet
+3. **Netzwerk-Problem:** Verbindungsprobleme zum Server
+
+**Lösungsansätze:**
+1. **Gitea Caching aktivieren:** Redis-Cache sollte Performance verbessern
+2. **Runner Status prüfen:** Sicherstellen, dass Runner nur mit Token läuft
+3. **Gitea Logs prüfen:** Server-Logs auf Fehler prüfen
+4. **Retry:** Push später erneut versuchen
+
+### 2. Gitea Runner ohne Token
+
+**Problem:** Runner ohne Registration Token läuft in Dauerschleife und bombardiert Gitea mit Requests, was zu Timeouts führt.
+
+**Lösung:**
+- ✅ Runner ist registriert (`data/.runner` existiert)
+- ✅ Registration Token ist in `.env` konfiguriert
+- ⏸️ Runner Container sind gestoppt (korrekt, bis Deployment abgeschlossen)
+
+**Runner starten (nach Cache-Aktivierung):**
+```bash
+cd deployment/gitea-runner
+docker compose up -d
+```
+
+## Nächste Schritte
+
+### 1. Gitea Caching aktivieren (Priorität: Hoch)
+
+Die geänderte `docker-compose.yml` muss auf den Server synchronisiert werden:
+
+```bash
+cd deployment/ansible
+ansible-playbook -i inventory/production.yml \
+  playbooks/sync-stacks.yml \
+  --vault-password-file secrets/.vault_pass
+```
+
+Dann Gitea neu starten:
+
+```bash
+cd deployment/ansible
+ansible-playbook -i inventory/production.yml \
+  playbooks/restart-gitea-with-cache.yml \
+  --vault-password-file secrets/.vault_pass
+```
+
+### 2. Git Push erneut versuchen
+
+Nach erfolgreicher Cache-Aktivierung und Gitea-Neustart:
+
+```bash
+cd /home/michael/dev/michaelschiemer
+git push origin staging
+```
+
+### 3. Pipeline beobachten
+
+Nach erfolgreichem Push:
+- Gitea Actions UI: `https://git.michaelschiemer.de/michael/michaelschiemer/actions`
+- Jobs beobachten: `changes`, `test`, `build`, `deploy-staging`
+- Deployment verifizieren
+
+### 4. Production Pipeline Test
+
+Nach erfolgreichem Staging-Test:
+- Test-Commit auf `main` Branch erstellen
+- Push zu `main`
+- Production Pipeline beobachten
+- Deployment verifizieren
+
+## Referenz
+
+- [Gitea Cache Aktivierung](./gitea-cache-activation.md)
+- [Pipeline Test Checklist](../guides/pipeline-test-checklist.md)
+- [Pipeline Testing Guide](../guides/pipeline-testing-guide.md)
+- [CI/CD Status](./ci-cd-status.md)
+
--- a/deployment/docs/status/staging-implementation-status.md
+++ b/deployment/docs/status/staging-implementation-status.md
@@ -0,0 +1,168 @@
+# Staging-Implementation Status
+
+**Datum**: 2025-01-31  
+**Status**: ✅ Implementierung abgeschlossen - Bereit für Tests
+
+## ✅ Abgeschlossene Aufgaben
+
+### Phase 1: Separate Datenbank-Stacks ✅
+
+- ✅ `deployment/stacks/postgresql-production/` erstellt
+  - `docker-compose.yml` mit postgres-production Container
+  - `README.md` mit vollständiger Dokumentation
+  - Separate Networks (`postgres-production-internal`)
+  - Separate Volumes (`postgres-production-data`)
+  - Backup-Konfiguration
+
+- ✅ `deployment/stacks/postgresql-staging/` erstellt
+  - `docker-compose.yml` mit postgres-staging Container
+  - `README.md` mit vollständiger Dokumentation
+  - Separate Networks (`postgres-staging-internal`)
+  - Separate Volumes (`postgres-staging-data`)
+  - Backup-Konfiguration (kürzere Retention: 3 Tage)
+
+### Phase 2: Application-Stacks angepasst ✅
+
+- ✅ `docker-compose.staging.yml` aktualisiert
+  - `DB_HOST=postgres-staging`
+  - Network `postgres-staging-internal` hinzugefügt
+  - Alle Services (staging-app, staging-queue-worker, staging-scheduler) verbunden
+
+- ✅ `docker-compose.postgres-override.yml` aktualisiert
+  - Network `postgres-production-internal` für Production
+  - Services (php, queue-worker, scheduler) verbunden
+
+- ✅ `docker-compose.staging-postgres-override.yml` aktualisiert
+  - Network `postgres-staging-internal` für Staging
+
+### Phase 3: Ansible-Integration ✅
+
+- ✅ `deployment/ansible/roles/postgresql-production/` erstellt
+  - Tasks für Production-Datenbank-Deployment
+  - Separate Variablen und Defaults
+
+- ✅ `deployment/ansible/roles/postgresql-staging/` erstellt
+  - Tasks für Staging-Datenbank-Deployment
+  - Separate Variablen und Defaults
+
+- ✅ `deployment/ansible/playbooks/setup-staging.yml` erstellt
+  - Deployed PostgreSQL-Staging Stack
+  - Deployed Staging Application Stack
+  - Verifizierung und Health-Checks
+
+- ✅ `deployment/ansible/inventory/group_vars/staging/vars.yml` erstellt
+  - Staging-spezifische Variablen
+  - `db_host_default: "postgres-staging"`
+  - `db_name_default: "michaelschiemer_staging"`
+
+- ✅ `deployment/ansible/playbooks/setup-infrastructure.yml` erweitert
+  - Production-Stack-Deployment mit korrekten Variablen
+  - Nutzt `postgresql-production` Role
+
+### Phase 4: CI/CD-Workflow ✅
+
+- ✅ Workflow bereits vorhanden (`.gitea/workflows/build-image.yml`)
+- ✅ Health-Checks erweitert für beide Environments
+- ✅ Keine Änderungen nötig - nutzt bereits korrekte Konfiguration
+
+### Phase 5: Dokumentation ✅
+
+- ✅ `deployment/stacks/postgresql-production/README.md` erstellt
+- ✅ `deployment/stacks/postgresql-staging/README.md` erstellt
+- ✅ `deployment/stacks/staging/README.md` aktualisiert
+- ✅ `deployment/stacks/production/README.md` aktualisiert
+- ✅ `deployment/docs/guides/migrate-to-separate-databases.md` erstellt
+- ✅ `deployment/docs/guides/staging-test-plan.md` erstellt
+- ✅ `deployment/docs/guides/production-database-connection.md` erstellt
+- ✅ `deployment/docs/guides/deployment-commands.md` aktualisiert
+
+### Phase 6: Code-Anpassungen ✅
+
+- ✅ `deployment/ansible/templates/application.env.j2` aktualisiert
+  - Automatische DB_HOST-Erkennung basierend auf `app_env`
+  - Unterstützt `db_host_default` Variable
+
+- ✅ `deployment/ansible/roles/application/tasks/sync.yml` erweitert
+  - Separate Passwort-Extraktion für Production/Staging
+  - `db_host` und `app_env` Variablen für Template
+
+- ✅ `deployment/ansible/inventory/group_vars/production/vars.yml` erweitert
+  - `db_host_default: "postgres-production"` hinzugefügt
+
+## ⚠️ Ausstehend: Testing
+
+### Phase 6: Testing & Verifikation
+
+- ⏳ **Staging-End-to-End-Test** (NÄCHSTER SCHRITT)
+  - [ ] PostgreSQL-Staging Stack auf Server starten
+  - [ ] Staging-Application Stack deployen
+  - [ ] Datenbank-Verbindung testen
+  - [ ] Application funktioniert korrekt
+  - [ ] Health-Checks erfolgreich
+
+- ⏳ **Production-Verifikation**
+  - [ ] Production-Stack nutzt `postgres-production`
+  - [ ] Migration von alter Datenbank (falls nötig)
+  - [ ] Rollback-Plan testen
+
+## 📋 Test-Checkliste
+
+### Vor dem Testen
+
+- [ ] SSH-Zugriff auf Production-Server
+- [ ] Ansible installiert und konfiguriert
+- [ ] Docker und Docker Compose auf Server installiert
+- [ ] Gitea Actions Runner läuft
+- [ ] Vault-Passwort verfügbar (für Ansible)
+
+### Während des Testens
+
+- [ ] PostgreSQL-Production Stack startet erfolgreich
+- [ ] PostgreSQL-Staging Stack startet erfolgreich
+- [ ] Networks werden korrekt erstellt
+- [ ] Application-Container können Datenbank erreichen
+- [ ] Health-Checks funktionieren
+- [ ] CI/CD-Workflow deployed erfolgreich
+
+### Nach dem Testen
+
+- [ ] Alle Container laufen stabil
+- [ ] Datenbank-Isolation funktioniert (Staging kann nicht auf Production-DB zugreifen)
+- [ ] Backups funktionieren für beide Datenbanken
+- [ ] Monitoring zeigt beide Datenbanken an
+
+## 🚀 Nächste Schritte
+
+1. **Testen auf Server** (siehe `deployment/docs/guides/staging-test-plan.md`)
+   - Phase 1: PostgreSQL-Stacks manuell starten
+   - Phase 2: Networks verifizieren
+   - Phase 3: Ansible-Setup ausführen
+   - Phase 4: CI/CD-Workflow testen
+
+2. **Production-Migration** (falls nötig)
+   - Backup erstellen
+   - Datenbank migrieren
+   - Application-Stack aktualisieren
+
+3. **Monitoring einrichten**
+   - Beide Datenbanken überwachen
+   - Alerts konfigurieren
+
+## 📊 Implementierungs-Statistik
+
+- **Erstellte Dateien**: 21
+- **Geänderte Dateien**: 10+
+- **Dokumentations-Seiten**: 5
+- **Ansible-Roles**: 2 neue
+- **Docker Compose Stacks**: 2 neue
+
+## ✅ Erfolgskriterien
+
+- ✅ Separate Datenbank-Stacks erstellt
+- ✅ Network-Isolation konfiguriert
+- ✅ Ansible-Integration vollständig
+- ✅ Dokumentation komplett
+- ⏳ Tests erfolgreich (ausstehend)
+
+**Status**: Bereit für Deployment und Tests! 🚀
+