fix: Gitea Traefik routing and connection pool optimization
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
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
- 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
This commit is contained in:
299
deployment/docs/guides/test-execution-plan.md
Normal file
299
deployment/docs/guides/test-execution-plan.md
Normal file
@@ -0,0 +1,299 @@
|
||||
# Test Execution Plan - Staging Setup
|
||||
|
||||
## Übersicht
|
||||
|
||||
Dieser Plan beschreibt die schrittweise Ausführung der Tests für das neue Staging-Setup mit separaten Datenbank-Stacks.
|
||||
|
||||
## Voraussetzungen prüfen
|
||||
|
||||
### 1. Lokale Verifikation (WSL/Local)
|
||||
|
||||
```bash
|
||||
# Syntax-Checks
|
||||
cd /home/michael/dev/michaelschiemer
|
||||
|
||||
# Ansible-Playbook-Syntax (falls Ansible installiert)
|
||||
ansible-playbook --syntax-check deployment/ansible/playbooks/verify-staging.yml
|
||||
|
||||
# Docker Compose-Syntax
|
||||
docker compose -f deployment/stacks/postgresql-production/docker-compose.yml config > /dev/null
|
||||
docker compose -f deployment/stacks/postgresql-staging/docker-compose.yml config > /dev/null
|
||||
docker compose -f deployment/stacks/staging/docker-compose.base.yml -f deployment/stacks/staging/docker-compose.staging.yml config > /dev/null
|
||||
```
|
||||
|
||||
### 2. Server-Verfügbarkeit
|
||||
|
||||
- SSH-Zugriff auf Production-Server
|
||||
- Docker und Docker Compose installiert
|
||||
- Ansible auf Control-Node installiert (optional)
|
||||
|
||||
## Test-Phasen
|
||||
|
||||
### Phase 1: Lokale Syntax-Verifikation
|
||||
|
||||
**Ziel**: Sicherstellen, dass alle Konfigurationsdateien syntaktisch korrekt sind.
|
||||
|
||||
**Schritte**:
|
||||
1. ✅ Ansible-Playbook-Syntax prüfen
|
||||
2. ✅ Docker Compose-Syntax prüfen
|
||||
3. ✅ YAML-Validierung
|
||||
4. ✅ Template-Syntax prüfen
|
||||
|
||||
**Erwartetes Ergebnis**: Alle Syntax-Checks erfolgreich
|
||||
|
||||
### Phase 2: PostgreSQL-Stacks testen (auf Server)
|
||||
|
||||
**Ziel**: Separate PostgreSQL-Stacks funktionieren korrekt.
|
||||
|
||||
#### 2.1 PostgreSQL-Production Stack
|
||||
|
||||
**Schritte**:
|
||||
```bash
|
||||
# Auf Production-Server
|
||||
cd ~/deployment/stacks/postgresql-production
|
||||
|
||||
# .env-Datei prüfen/erstellen
|
||||
cat .env # Sollte POSTGRES_PASSWORD enthalten
|
||||
|
||||
# Stack starten
|
||||
docker compose up -d
|
||||
|
||||
# Status prüfen
|
||||
docker compose ps
|
||||
|
||||
# Health-Check
|
||||
docker exec postgres-production pg_isready -U postgres -d michaelschiemer
|
||||
```
|
||||
|
||||
**Erwartetes Ergebnis**:
|
||||
- Container läuft
|
||||
- PostgreSQL akzeptiert Verbindungen
|
||||
- Datenbank `michaelschiemer` existiert
|
||||
|
||||
#### 2.2 PostgreSQL-Staging Stack
|
||||
|
||||
**Schritte**:
|
||||
```bash
|
||||
# Auf Production-Server
|
||||
cd ~/deployment/stacks/postgresql-staging
|
||||
|
||||
# .env-Datei prüfen/erstellen
|
||||
cat .env # Sollte POSTGRES_PASSWORD enthalten
|
||||
|
||||
# Stack starten
|
||||
docker compose up -d
|
||||
|
||||
# Status prüfen
|
||||
docker compose ps
|
||||
|
||||
# Health-Check
|
||||
docker exec postgres-staging pg_isready -U postgres -d michaelschiemer_staging
|
||||
```
|
||||
|
||||
**Erwartetes Ergebnis**:
|
||||
- Container läuft
|
||||
- PostgreSQL akzeptiert Verbindungen
|
||||
- Datenbank `michaelschiemer_staging` existiert
|
||||
|
||||
### Phase 3: Networks verifizieren
|
||||
|
||||
**Ziel**: Alle benötigten Docker-Networks existieren.
|
||||
|
||||
**Schritte**:
|
||||
```bash
|
||||
# Auf Production-Server
|
||||
docker network ls | grep -E "(traefik-public|staging-internal|postgres-production-internal|postgres-staging-internal|app-internal)"
|
||||
```
|
||||
|
||||
**Erwartetes Ergebnis**: Alle Networks existieren
|
||||
|
||||
**Falls fehlend**: Networks werden beim Stack-Start automatisch erstellt
|
||||
|
||||
### Phase 4: Ansible-Setup testen
|
||||
|
||||
**Ziel**: Ansible-Playbooks funktionieren korrekt.
|
||||
|
||||
#### 4.1 Staging-Setup ausführen
|
||||
|
||||
**Schritte**:
|
||||
```bash
|
||||
# Auf Control-Node (lokal in WSL)
|
||||
cd ~/dev/michaelschiemer/deployment/ansible
|
||||
|
||||
# Dry-Run (Check-Mode)
|
||||
ansible-playbook -i inventory/production.yml \
|
||||
playbooks/setup-staging.yml \
|
||||
--check \
|
||||
--ask-vault-pass
|
||||
|
||||
# Echt ausführen
|
||||
ansible-playbook -i inventory/production.yml \
|
||||
playbooks/setup-staging.yml \
|
||||
--ask-vault-pass
|
||||
```
|
||||
|
||||
**Erwartetes Ergebnis**:
|
||||
- Playbook läuft durch ohne Fehler
|
||||
- PostgreSQL-Staging Stack deployed
|
||||
- Staging Application Stack deployed
|
||||
- Alle Services laufen
|
||||
|
||||
#### 4.2 Verifikations-Playbook ausführen
|
||||
|
||||
**Schritte**:
|
||||
```bash
|
||||
# Auf Control-Node
|
||||
cd ~/dev/michaelschiemer/deployment/ansible
|
||||
|
||||
ansible-playbook -i inventory/production.yml \
|
||||
playbooks/verify-staging.yml
|
||||
```
|
||||
|
||||
**Erwartetes Ergebnis**:
|
||||
- Alle Verifikationen erfolgreich
|
||||
- PostgreSQL-Staging: RUNNING
|
||||
- staging-app: RUNNING
|
||||
- Health-Checks: SUCCESS
|
||||
|
||||
### Phase 5: Datenbank-Verbindungen testen
|
||||
|
||||
**Ziel**: Application-Container können auf ihre jeweiligen Datenbanken zugreifen.
|
||||
|
||||
#### 5.1 Staging-Datenbank-Verbindung
|
||||
|
||||
**Schritte**:
|
||||
```bash
|
||||
# Auf Production-Server
|
||||
docker exec staging-app php -r "
|
||||
\$dsn = 'pgsql:host=postgres-staging;port=5432;dbname=michaelschiemer_staging';
|
||||
\$pdo = new PDO(\$dsn, 'postgres', trim(file_get_contents('/var/www/html/storage/secrets/db_user_password')));
|
||||
echo 'Connection successful: ' . \$pdo->query('SELECT version()')->fetchColumn();
|
||||
"
|
||||
```
|
||||
|
||||
**Erwartetes Ergebnis**: Connection successful mit PostgreSQL-Version
|
||||
|
||||
#### 5.2 Production-Datenbank-Verbindung
|
||||
|
||||
**Schritte**:
|
||||
```bash
|
||||
# Auf Production-Server
|
||||
docker exec php php -r "
|
||||
\$dsn = 'pgsql:host=postgres-production;port=5432;dbname=michaelschiemer';
|
||||
\$pdo = new PDO(\$dsn, 'postgres', trim(file_get_contents('/var/www/html/storage/secrets/db_user_password')));
|
||||
echo 'Connection successful: ' . \$pdo->query('SELECT version()')->fetchColumn();
|
||||
"
|
||||
```
|
||||
|
||||
**Erwartetes Ergebnis**: Connection successful mit PostgreSQL-Version
|
||||
|
||||
### Phase 6: Health-Checks
|
||||
|
||||
**Ziel**: Application-Endpoints sind erreichbar und funktionieren.
|
||||
|
||||
#### 6.1 Basic Health Check
|
||||
|
||||
**Schritte**:
|
||||
```bash
|
||||
# Staging
|
||||
curl -f -k https://staging.michaelschiemer.de/health
|
||||
|
||||
# Production
|
||||
curl -f -k https://michaelschiemer.de/health
|
||||
```
|
||||
|
||||
**Erwartetes Ergebnis**: HTTP 200 OK
|
||||
|
||||
#### 6.2 Extended Health Check
|
||||
|
||||
**Schritte**:
|
||||
```bash
|
||||
# Staging
|
||||
curl -f -k https://staging.michaelschiemer.de/admin/health/api/summary | jq .
|
||||
|
||||
# Production
|
||||
curl -f -k https://michaelschiemer.de/admin/health/api/summary | jq .
|
||||
```
|
||||
|
||||
**Erwartetes Ergebnis**: JSON mit `"overall_status": "healthy"`
|
||||
|
||||
### Phase 7: CI/CD-Workflow testen
|
||||
|
||||
**Ziel**: Automatisches Deployment funktioniert.
|
||||
|
||||
**Schritte**:
|
||||
1. Kleine Änderung im Code vornehmen
|
||||
2. Commit auf `staging`-Branch pushen
|
||||
3. Gitea Actions Workflow beobachten
|
||||
4. Nach erfolgreichem Deployment:
|
||||
- Health-Check prüfen
|
||||
- Code-Änderung verifizieren
|
||||
|
||||
**Erwartetes Ergebnis**:
|
||||
- Workflow läuft erfolgreich durch
|
||||
- Deployment erfolgreich
|
||||
- Health-Checks bestehen
|
||||
|
||||
### Phase 8: Datenbank-Isolation testen
|
||||
|
||||
**Ziel**: Staging und Production haben getrennte Datenbanken.
|
||||
|
||||
**Schritte**:
|
||||
```bash
|
||||
# Auf Production-Server
|
||||
|
||||
# Test-Daten in Staging-DB schreiben
|
||||
docker exec staging-app php -r "
|
||||
\$dsn = 'pgsql:host=postgres-staging;port=5432;dbname=michaelschiemer_staging';
|
||||
\$pdo = new PDO(\$dsn, 'postgres', trim(file_get_contents('/var/www/html/storage/secrets/db_user_password')));
|
||||
\$pdo->exec('CREATE TABLE IF NOT EXISTS test_isolation (id SERIAL PRIMARY KEY, env VARCHAR(50))');
|
||||
\$pdo->exec('INSERT INTO test_isolation (env) VALUES (\'staging\')');
|
||||
echo 'Staging data inserted.';
|
||||
"
|
||||
|
||||
# Prüfen, dass Test-Daten NICHT in Production-DB sind
|
||||
docker exec postgres-production psql -U postgres -d michaelschiemer -c "SELECT * FROM test_isolation;" || echo "✅ Isolation confirmed: test_isolation table not in production"
|
||||
```
|
||||
|
||||
**Erwartetes Ergebnis**:
|
||||
- Test-Daten in Staging-DB vorhanden
|
||||
- Test-Daten NICHT in Production-DB vorhanden
|
||||
|
||||
## Fehlerbehebung
|
||||
|
||||
### Häufige Probleme
|
||||
|
||||
1. **PostgreSQL-Container startet nicht**
|
||||
- Prüfe `.env`-Datei (POSTGRES_PASSWORD gesetzt?)
|
||||
- Prüfe Logs: `docker logs postgres-production` oder `docker logs postgres-staging`
|
||||
- Prüfe Volumes: `docker volume ls`
|
||||
|
||||
2. **Network-Verbindung fehlgeschlagen**
|
||||
- Prüfe Networks: `docker network ls`
|
||||
- Prüfe Container-Networks: `docker inspect <container> | grep -A 10 Networks`
|
||||
- Stelle sicher, dass Container im richtigen Network sind
|
||||
|
||||
3. **Datenbank-Verbindung fehlgeschlagen**
|
||||
- Prüfe DB_HOST in Application-Container
|
||||
- Prüfe DB_PASSWORD (Docker Secret)
|
||||
- Prüfe Network-Verbindung (siehe oben)
|
||||
|
||||
4. **Health-Check fehlgeschlagen**
|
||||
- Prüfe Container-Status: `docker ps`
|
||||
- Prüfe Application-Logs: `docker logs staging-app`
|
||||
- Prüfe Nginx-Logs: `docker logs staging-nginx`
|
||||
|
||||
## Test-Ergebnisse dokumentieren
|
||||
|
||||
Nach jedem Test:
|
||||
- ✅ Erfolgreich
|
||||
- ❌ Fehlgeschlagen (mit Fehlerbeschreibung)
|
||||
- ⚠️ Teilweise erfolgreich (mit Details)
|
||||
|
||||
## Nächste Schritte nach erfolgreichen Tests
|
||||
|
||||
1. ✅ Alle Tests bestanden
|
||||
2. Dokumentation aktualisieren (falls nötig)
|
||||
3. Production-Deployment vorbereiten
|
||||
4. Monitoring einrichten
|
||||
|
||||
Reference in New Issue
Block a user