# 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**:
```bash
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**:
```yaml
# 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
```bash
# 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
```bash
# 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
```bash
# 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
```bash
# 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