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

deployment/ansible/playbooks/TRAEFIK_RESTART_DIAGNOSIS.md

@@ -0,0 +1,157 @@
+# Traefik Restart Loop - Diagnose & Lösung
+
+## Problem
+
+Traefik wird regelmäßig gestoppt mit den Meldungen:
+- "I have to go..."
+- "Stopping server gracefully"
+
+Dies führt zu:
+- ACME-Challenge-Fehlern
+- Externen Timeouts
+- Unterbrechungen der SSL-Zertifikats-Erneuerung
+
+## Durchgeführte Diagnose
+
+### 1. Erweiterte Diagnose (`diagnose-traefik-restarts.yml`)
+
+**Geprüfte Bereiche:**
+- ✅ Systemd-Timer (keine gefunden die Traefik stoppen)
+- ✅ Alle User-Crontabs (keine gefunden)
+- ✅ System-wide Cronjobs (keine gefunden)
+- ✅ Gitea Workflows (gefunden: `build-image.yml`, `manual-deploy.yml` - rufen aber keine Traefik-Restarts auf)
+- ✅ Custom Systemd Services/Timers (keine gefunden)
+- ✅ At Jobs (keine gefunden)
+- ✅ Docker Compose Watch Mode (nicht aktiviert)
+- ✅ Ansible `traefik_auto_restart` Einstellung (prüfbar)
+- ✅ Port-Konfiguration (Ports 80/443 korrekt auf Traefik gemappt)
+- ✅ Netzwerk-Konfiguration (geprüft)
+
+**Ergebnisse:**
+- ❌ Keine automatischen Restart-Mechanismen gefunden
+- ✅ Ports 80/443 sind korrekt konfiguriert
+- ✅ Traefik läuft stabil (keine Restarts während 2-minütiger Überwachung)
+
+### 2. acme.json Berechtigungen (`fix-traefik-acme-permissions.yml`)
+
+**Ergebnisse:**
+- ✅ acme.json hat korrekte Berechtigungen (chmod 600)
+- ✅ Owner/Group korrekt (deploy:deploy)
+- ✅ Traefik Container kann auf acme.json schreiben
+
+### 3. Auto-Restart-Mechanismen (`disable-traefik-auto-restarts.yml`)
+
+**Ergebnisse:**
+- ❌ Keine Cronjobs gefunden die Traefik restarten
+- ❌ Keine Systemd Timers/Services gefunden
+- ℹ️ Ansible `traefik_auto_restart` kann in group_vars überschrieben werden
+
+### 4. Traefik Stabilisierung (`stabilize-traefik.yml`)
+
+**Ergebnisse:**
+- ✅ Traefik läuft stabil (41 Minuten Uptime)
+- ✅ Keine Restarts während 2-minütiger Überwachung
+- ✅ Traefik ist healthy
+- ✅ Ports 80/443 korrekt konfiguriert
+
+## Mögliche Ursachen (nicht gefunden, aber zu prüfen)
+
+1. **Docker-Service-Restarts**: Am 08.11. um 16:12:58 wurde der Docker-Service gestoppt, was alle Container gestoppt hat
+   - Prüfe: `journalctl -u docker.service` für regelmäßige Stops
+   - Prüfe: System-Reboots oder Kernel-Updates
+
+2. **Unattended-Upgrades**: Können zu Reboots führen
+   - Prüfe: `journalctl -u unattended-upgrades`
+
+3. **Manuelle Restarts**: Jemand könnte Traefik manuell restarten
+   - Prüfe: Docker-Events für Stop-Events
+   - Prüfe: SSH-Login-Historie
+
+4. **Gitea Workflows**: Können indirekt Traefik beeinflussen
+   - `build-image.yml`: Ruft `deploy-image.yml` auf (keine Traefik-Restarts)
+   - `manual-deploy.yml`: Ruft `deploy-image.yml` auf (keine Traefik-Restarts)
+
+## Verfügbare Playbooks
+
+### Diagnose
+```bash
+# Erweiterte Diagnose durchführen
+ansible-playbook -i inventory/production.yml \
+  playbooks/diagnose-traefik-restarts.yml \
+  --vault-password-file secrets/.vault_pass
+```
+
+### acme.json Berechtigungen
+```bash
+# acme.json Berechtigungen prüfen und korrigieren
+ansible-playbook -i inventory/production.yml \
+  playbooks/fix-traefik-acme-permissions.yml \
+  --vault-password-file secrets/.vault_pass
+```
+
+### Auto-Restarts deaktivieren
+```bash
+# Prüfe Auto-Restart-Mechanismen
+ansible-playbook -i inventory/production.yml \
+  playbooks/disable-traefik-auto-restarts.yml \
+  --vault-password-file secrets/.vault_pass
+```
+
+### Traefik stabilisieren
+```bash
+# Traefik stabilisieren und überwachen (10 Minuten)
+ansible-playbook -i inventory/production.yml \
+  playbooks/stabilize-traefik.yml \
+  -e "traefik_stabilize_wait_minutes=10" \
+  --vault-password-file secrets/.vault_pass
+```
+
+## Empfohlene nächste Schritte
+
+1. **Längere Überwachung**: Führe `stabilize-traefik.yml` mit 10 Minuten aus, um zu sehen, ob Restarts auftreten
+   ```bash
+   ansible-playbook -i inventory/production.yml \
+     playbooks/stabilize-traefik.yml \
+     -e "traefik_stabilize_wait_minutes=10" \
+     --vault-password-file secrets/.vault_pass
+   ```
+
+2. **Docker-Events überwachen**: Prüfe Docker-Events für Stop-Events
+   ```bash
+   docker events --filter container=traefik --format "{{.Time}} {{.Action}}"
+   ```
+
+3. **Traefik-Logs prüfen**: Suche nach Stop-Meldungen
+   ```bash
+   cd /home/deploy/deployment/stacks/traefik
+   docker compose logs traefik | grep -E "I have to go|Stopping server gracefully|SIGTERM|SIGINT"
+   ```
+
+4. **Docker-Service-Logs prüfen**: Prüfe ob Docker-Service regelmäßig gestoppt wird
+   ```bash
+   journalctl -u docker.service --since "7 days ago" | grep -i "stop\|restart"
+   ```
+
+5. **System-Reboots prüfen**: Prüfe ob regelmäßige Reboots auftreten
+   ```bash
+   last reboot
+   uptime
+   ```
+
+## Wichtige Erkenntnisse
+
+- ✅ **Keine automatischen Restart-Mechanismen gefunden**: Keine Cronjobs, Systemd-Timer oder Services die Traefik regelmäßig stoppen
+- ✅ **acme.json ist korrekt konfiguriert**: Berechtigungen (600) und Container-Zugriff sind korrekt
+- ✅ **Ports sind korrekt**: Ports 80/443 zeigen auf Traefik
+- ✅ **Traefik läuft stabil**: Während der 2-minütigen Überwachung keine Restarts
+- ⚠️ **Docker-Service wurde einmalig gestoppt**: Am 08.11. um 16:12:58 - könnte die Ursache sein
+
+## Fazit
+
+Die Diagnose zeigt, dass **keine automatischen Restart-Mechanismen** aktiv sind. Die "I have to go..." Meldungen stammen wahrscheinlich von:
+1. Einmaligem Docker-Service-Stop (08.11. 16:12:58)
+2. System-Reboots (nicht in der Historie sichtbar, aber möglich)
+3. Manuellen Restarts (nicht nachweisbar)
+
+**Empfehlung**: Überwache Traefik für 10-30 Minuten mit `stabilize-traefik.yml`, um zu sehen, ob weitere Restarts auftreten. Wenn keine Restarts auftreten, war das Problem wahrscheinlich der einmalige Docker-Service-Stop.
+