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:
247
deployment/docs/guides/manual-server-test.md
Normal file
247
deployment/docs/guides/manual-server-test.md
Normal file
@@ -0,0 +1,247 @@
|
||||
# Manuelle Server-Tests - Anleitung
|
||||
|
||||
## Voraussetzungen
|
||||
|
||||
- SSH-Zugriff auf Production-Server: `ssh production`
|
||||
- Docker und Docker Compose installiert
|
||||
- Zugriff auf `~/deployment` Verzeichnis
|
||||
|
||||
## Test-Phasen
|
||||
|
||||
### Phase 1: PostgreSQL-Stacks prüfen
|
||||
|
||||
#### 1.1 PostgreSQL-Production Stack
|
||||
|
||||
```bash
|
||||
# Auf Production-Server
|
||||
ssh production
|
||||
|
||||
# Zum Stack-Verzeichnis wechseln
|
||||
cd ~/deployment/stacks/postgresql-production
|
||||
|
||||
# .env-Datei prüfen/erstellen
|
||||
cat .env
|
||||
# Sollte enthalten:
|
||||
# POSTGRES_DB=michaelschiemer
|
||||
# POSTGRES_USER=postgres
|
||||
# POSTGRES_PASSWORD=<password>
|
||||
|
||||
# Stack starten
|
||||
docker compose up -d
|
||||
|
||||
# Status prüfen
|
||||
docker compose ps
|
||||
|
||||
# Health-Check
|
||||
docker exec postgres-production pg_isready -U postgres -d michaelschiemer
|
||||
# Erwartete Ausgabe: postgres-production:5432 - accepting connections
|
||||
```
|
||||
|
||||
#### 1.2 PostgreSQL-Staging Stack
|
||||
|
||||
```bash
|
||||
# Auf Production-Server
|
||||
cd ~/deployment/stacks/postgresql-staging
|
||||
|
||||
# .env-Datei prüfen/erstellen
|
||||
cat .env
|
||||
# Sollte enthalten:
|
||||
# POSTGRES_DB=michaelschiemer_staging
|
||||
# POSTGRES_USER=postgres
|
||||
# POSTGRES_PASSWORD=<password>
|
||||
|
||||
# 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
|
||||
# Erwartete Ausgabe: postgres-staging:5432 - accepting connections
|
||||
```
|
||||
|
||||
### Phase 2: Networks verifizieren
|
||||
|
||||
```bash
|
||||
# Auf Production-Server
|
||||
docker network ls | grep -E "(traefik-public|staging-internal|postgres-production-internal|postgres-staging-internal|app-internal)"
|
||||
|
||||
# Erwartete Ausgabe (alle sollten existieren):
|
||||
# traefik-public
|
||||
# staging-internal
|
||||
# postgres-production-internal
|
||||
# postgres-staging-internal
|
||||
# app-internal
|
||||
```
|
||||
|
||||
**Falls Networks fehlen**: Sie werden beim Stack-Start automatisch erstellt.
|
||||
|
||||
### Phase 3: Staging-Application-Stack prüfen
|
||||
|
||||
```bash
|
||||
# Auf Production-Server
|
||||
cd ~/deployment/stacks/staging
|
||||
|
||||
# Docker Compose-Dateien prüfen
|
||||
ls -la docker-compose*.yml
|
||||
|
||||
# Stack-Status prüfen
|
||||
docker compose -f docker-compose.base.yml -f docker-compose.staging.yml ps
|
||||
|
||||
# Oder falls im Root-Verzeichnis:
|
||||
cd ~/deployment
|
||||
docker compose -f docker-compose.base.yml -f docker-compose.staging.yml ps
|
||||
```
|
||||
|
||||
### Phase 4: Datenbank-Verbindungen testen
|
||||
|
||||
#### 4.1 Staging-Datenbank-Verbindung
|
||||
|
||||
```bash
|
||||
# Auf Production-Server
|
||||
docker exec staging-app php -r "
|
||||
\$dsn = 'pgsql:host=postgres-staging;port=5432;dbname=michaelschiemer_staging';
|
||||
\$pass = trim(file_get_contents('/var/www/html/storage/secrets/db_user_password'));
|
||||
\$pdo = new PDO(\$dsn, 'postgres', \$pass);
|
||||
echo 'Connection successful: ' . \$pdo->query('SELECT version()')->fetchColumn();
|
||||
"
|
||||
```
|
||||
|
||||
**Erwartete Ausgabe**: `Connection successful: PostgreSQL 16.x...`
|
||||
|
||||
#### 4.2 Production-Datenbank-Verbindung
|
||||
|
||||
```bash
|
||||
# Auf Production-Server
|
||||
docker exec php php -r "
|
||||
\$dsn = 'pgsql:host=postgres-production;port=5432;dbname=michaelschiemer';
|
||||
\$pass = trim(file_get_contents('/var/www/html/storage/secrets/db_user_password'));
|
||||
\$pdo = new PDO(\$dsn, 'postgres', \$pass);
|
||||
echo 'Connection successful: ' . \$pdo->query('SELECT version()')->fetchColumn();
|
||||
"
|
||||
```
|
||||
|
||||
**Erwartete Ausgabe**: `Connection successful: PostgreSQL 16.x...`
|
||||
|
||||
### Phase 5: Health-Checks
|
||||
|
||||
#### 5.1 Basic Health Check
|
||||
|
||||
```bash
|
||||
# Staging
|
||||
curl -f -k https://staging.michaelschiemer.de/health
|
||||
|
||||
# Production
|
||||
curl -f -k https://michaelschiemer.de/health
|
||||
```
|
||||
|
||||
**Erwartete Ausgabe**: HTTP 200 OK
|
||||
|
||||
#### 5.2 Extended Health Check
|
||||
|
||||
```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 .
|
||||
```
|
||||
|
||||
**Erwartete Ausgabe**: JSON mit `"overall_status": "healthy"`
|
||||
|
||||
### Phase 6: Quick-Start-Script nutzen
|
||||
|
||||
```bash
|
||||
# Auf Production-Server
|
||||
cd ~/deployment
|
||||
|
||||
# Script ausführbar machen (falls nötig)
|
||||
chmod +x scripts/staging-quick-start.sh
|
||||
|
||||
# Script ausführen
|
||||
./scripts/staging-quick-start.sh
|
||||
```
|
||||
|
||||
Das Script bietet ein interaktives Menü für alle Tests.
|
||||
|
||||
### Phase 7: Ansible-Verifikation (falls Ansible installiert)
|
||||
|
||||
```bash
|
||||
# Auf Control-Node (lokal)
|
||||
cd ~/dev/michaelschiemer/deployment/ansible
|
||||
|
||||
# Staging-Verifikation
|
||||
ansible-playbook -i inventory/production.yml \
|
||||
playbooks/verify-staging.yml
|
||||
|
||||
# Production-Verifikation
|
||||
ansible-playbook -i inventory/production.yml \
|
||||
playbooks/verify-production.yml
|
||||
```
|
||||
|
||||
## Fehlerbehebung
|
||||
|
||||
### PostgreSQL-Container startet nicht
|
||||
|
||||
```bash
|
||||
# Logs prüfen
|
||||
docker logs postgres-production
|
||||
docker logs postgres-staging
|
||||
|
||||
# .env-Datei prüfen
|
||||
cat ~/deployment/stacks/postgresql-production/.env
|
||||
cat ~/deployment/stacks/postgresql-staging/.env
|
||||
|
||||
# Volumes prüfen
|
||||
docker volume ls | grep postgres
|
||||
```
|
||||
|
||||
### Network-Verbindung fehlgeschlagen
|
||||
|
||||
```bash
|
||||
# Container-Networks prüfen
|
||||
docker inspect staging-app | grep -A 10 Networks
|
||||
docker inspect postgres-staging | grep -A 10 Networks
|
||||
|
||||
# Network-Verbindung testen
|
||||
docker exec staging-app ping -c 2 postgres-staging
|
||||
```
|
||||
|
||||
### Datenbank-Verbindung fehlgeschlagen
|
||||
|
||||
```bash
|
||||
# Secrets prüfen
|
||||
docker exec staging-app ls -la /var/www/html/storage/secrets/
|
||||
docker exec staging-app cat /var/www/html/storage/secrets/db_user_password
|
||||
|
||||
# Environment-Variablen prüfen
|
||||
docker exec staging-app env | grep DB_
|
||||
```
|
||||
|
||||
### Health-Check fehlgeschlagen
|
||||
|
||||
```bash
|
||||
# Container-Status prüfen
|
||||
docker ps | grep staging
|
||||
|
||||
# Application-Logs prüfen
|
||||
docker logs staging-app --tail 50
|
||||
docker logs staging-nginx --tail 50
|
||||
```
|
||||
|
||||
## Test-Ergebnisse dokumentieren
|
||||
|
||||
Nach jedem Test:
|
||||
- ✅ Erfolgreich
|
||||
- ❌ Fehlgeschlagen (mit Fehlerbeschreibung)
|
||||
- ⚠️ Teilweise erfolgreich (mit Details)
|
||||
|
||||
## Nächste Schritte
|
||||
|
||||
Nach erfolgreichen Tests:
|
||||
1. CI/CD-Workflow testen (Commit auf `staging`-Branch)
|
||||
2. Datenbank-Isolation verifizieren
|
||||
3. Backup-Strategie testen
|
||||
4. Monitoring einrichten
|
||||
|
||||
Reference in New Issue
Block a user