michaelschiemer/docs/deployment/production-compose-consolidation-plan.md

Plan: Konsolidierung der Production Docker-Compose Konfiguration

Datum: 2025-11-04
Ziel: docker-compose.production.yml im Root verwenden statt deployment/stacks/application/docker-compose.yml

Aktuelle Situation

Datei 1: docker-compose.production.yml (Repository Root)

Typ: Override-Datei f?r docker-compose.base.yml
Status: ? Aktiv verwendet in Deployment-Skripten
Services: web, php, db, redis, queue-worker, certbot
Struktur: Base + Override Pattern

Verwendung:

docker compose -f docker-compose.base.yml -f docker-compose.production.yml up -d

Datei 2: deployment/stacks/application/docker-compose.yml

Typ: Vollst?ndige Docker-Compose-Definition
Status: ?? Wird noch in einigen Dokumenten referenziert, aber vermutlich nicht mehr aktiv verwendet
Services: app, nginx, redis, queue-worker, scheduler
Struktur: Standalone-Definition

Referenzen gefunden in:

• deployment/ansible/inventory/production.yml
• deployment/docs/reference/application-stack.md
• deployment/README.md
• Verschiedene Test-Dokumente

Vergleich der Services

Service	docker-compose.production.yml	application/docker-compose.yml
PHP Runtime	php	app
Web Server	web	nginx
Database	db	? (nicht definiert, nutzt externen PostgreSQL)
Redis	redis	redis
Queue Worker	queue-worker	queue-worker
Scheduler	? (nicht definiert)	scheduler ?
Certbot	certbot ?	?

Unterschiede

1. Service-Namen

• production.yml: web, php (konsistent mit base.yml)
• application.yml: nginx, app (eigene Namenskonvention)

2. Scheduler Service

• production.yml: ? Fehlt
• application.yml: ? Vorhanden (scheduler)

3. Certbot Service

• production.yml: ? Vorhanden (f?r Let's Encrypt)
• application.yml: ? Fehlt

4. Database Service

• production.yml: ? Definiert (db)
• application.yml: ? Nutzt externen PostgreSQL-Stack (postgres)

5. Netzwerk-Konfiguration

• production.yml: Nutzt frontend, backend, cache (aus base.yml)
• application.yml: Nutzt app-internal, traefik-public (external networks)

Problemanalyse

Problem 1: Service-Namen-Mismatch

Die Service-Namen sind unterschiedlich, was zu Verwirrung f?hrt:

• php vs app
• web vs nginx

Problem 2: Fehlender Scheduler

docker-compose.production.yml hat keinen scheduler Service, der in application/docker-compose.yml vorhanden ist.

Problem 3: Unterschiedliche Architektur

• production.yml: Nutzt Base+Override Pattern mit db Service
• application.yml: Nutzt externen PostgreSQL-Stack (postgres)

L?sungsplan

Phase 1: Scheduler zu production.yml hinzuf?gen

Ziel: scheduler Service in docker-compose.production.yml hinzuf?gen

Begr?ndung: Der Scheduler ist wichtig f?r Cron-Jobs und sollte in Production verf?gbar sein.

Implementierung:

# In docker-compose.production.yml hinzuf?gen:
scheduler:
  # Production restart policy
  restart: always
  
  # Use same build as php service
  image: git.michaelschiemer.de:5000/framework:latest
  
  # Production volumes
  volumes:
    - /home/deploy/michaelschiemer/current:/var/www/html:ro
    - storage:/var/www/html/storage:rw
    - var-data:/var/www/html/var:rw
    - /home/deploy/michaelschiemer/shared/.env.production:/var/www/html/.env:ro
  
  environment:
    - APP_ENV=production
    - APP_DEBUG=false
    # Use Docker Secrets
    - DB_PASSWORD_FILE=/run/secrets/db_user_password
    - REDIS_PASSWORD_FILE=/run/secrets/redis_password
    - APP_KEY_FILE=/run/secrets/app_key
    - VAULT_ENCRYPTION_KEY_FILE=/run/secrets/vault_encryption_key
  secrets:
    - db_user_password
    - redis_password
    - app_key
    - vault_encryption_key
  
  command: php console.php scheduler:run
  
  # Health checks
  healthcheck:
    test: ["CMD-SHELL", "php -r 'exit(0);' && test -f /var/www/html/console.php || exit 1"]
    interval: 60s
    timeout: 10s
    retries: 3
    start_period: 30s
  
  depends_on:
    db:
      condition: service_healthy
    redis:
      condition: service_healthy
    php:
      condition: service_healthy

Phase 2: Referenzen aktualisieren

Ziel: Alle Referenzen auf application/docker-compose.yml entfernen/aktualisieren

Dateien zu aktualisieren:

1. deployment/ansible/inventory/production.yml - compose_file entfernen/aktualisieren
2. deployment/docs/reference/application-stack.md - Dokumentation aktualisieren
3. deployment/README.md - Referenzen aktualisieren
4. Test-Dokumente - Referenzen aktualisieren

Phase 3: application/docker-compose.yml entfernen

Voraussetzungen:

• ? Alle Referenzen aktualisiert
• ? Scheduler in production.yml hinzugef?gt
• ? Deployment-Skripte testen
• ? Production-Deployment erfolgreich

Aktion:

• deployment/stacks/application/docker-compose.yml l?schen
• deployment/stacks/application/docker-compose.base.yml pr?fen (falls redundant)
• Backup erstellen vor L?schung

Phase 4: PostgreSQL-Stack Integration

Wichtig: Da docker-compose.production.yml aktuell einen eigenen db Service definiert, aber wir zum PostgreSQL-Stack verbinden wollen:

Option A: db Service aus production.yml entfernen

• Nutzt externen PostgreSQL-Stack (postgres)
• F?gt app-internal Netzwerk hinzu (via docker-compose.postgres-override.yml)

Option B: db Service behalten (wenn separate Production-DB gew?nscht)

• Nutzt eigenen db Service
• Keine Verbindung zum PostgreSQL-Stack n?tig

Empfehlung: Option A - Nutze externen PostgreSQL-Stack f?r Konsistenz

Migrationspfad

Schritt 1: Scheduler hinzuf?gen

# 1. Scheduler zu docker-compose.production.yml hinzuf?gen
# 2. Testen lokal
docker compose -f docker-compose.base.yml -f docker-compose.production.yml config

Schritt 2: Referenzen pr?fen

# Alle Referenzen finden
grep -r "stacks/application/docker-compose" deployment/
grep -r "application/docker-compose" deployment/

Schritt 3: Referenzen aktualisieren

• Dokumentation aktualisieren
• Ansible-Playbooks pr?fen
• Deployment-Skripte aktualisieren

Schritt 4: Testing

# Test Production-Deployment
docker compose -f docker-compose.base.yml \
               -f docker-compose.production.yml \
               -f docker-compose.postgres-override.yml \
               config

# Alle Services pr?fen
docker compose -f docker-compose.base.yml \
               -f docker-compose.production.yml \
               -f docker-compose.postgres-override.yml \
               ps

Schritt 5: Cleanup

# Backup erstellen
cp deployment/stacks/application/docker-compose.yml \
   deployment/stacks/application/docker-compose.yml.backup

# Datei entfernen
rm deployment/stacks/application/docker-compose.yml

Checkliste

• Scheduler Service zu docker-compose.production.yml hinzuf?gen
• Alle Referenzen auf application/docker-compose.yml finden
• Dokumentation aktualisieren
• Ansible-Playbooks aktualisieren
• Deployment-Skripte testen
• Production-Deployment testen
• Backup von application/docker-compose.yml erstellen
• application/docker-compose.yml entfernen
• docker-compose.postgres-override.yml integrieren (f?r PostgreSQL-Stack)

Risiken

Risiko 1: Service-Namen-?nderungen

Problem: Services haben unterschiedliche Namen (php vs app, web vs nginx)

L?sung:

• Deployment-Skripte m?ssen Service-Namen aktualisieren
• php statt app, web statt nginx

Risiko 2: Fehlende Features

Problem: application/docker-compose.yml k?nnte Features haben, die in production.yml fehlen

L?sung:

• Vergleich durchf?hren
• Scheduler bereits identifiziert und wird hinzugef?gt
• Weitere Features pr?fen

Risiko 3: Referenzen vergessen

Problem: Versteckte Referenzen k?nnten zu Fehlern f?hren

L?sung:

• Systematische Suche nach allen Referenzen
• Tests durchf?hren

N?chste Schritte

1. ? Plan erstellt
2. ? Scheduler zu docker-compose.production.yml hinzuf?gen
3. ? Referenzen systematisch finden und aktualisieren
4. ? Testing durchf?hren
5. ? Cleanup: application/docker-compose.yml entfernen