docker-compose.override.yml: lokale Anpassungen

Liegt neben docker-compose.yml eine docker-compose.override.yml, lädt Compose sie automatisch mit und mischt sie darüber. Das gilt, solange man keine Datei per -f angibt. So bleibt die Hauptdatei für alle Installationen gleich, und die Besonderheiten eines Rechners stehen getrennt daneben.

Die Regeln beim Mischen:

• Einzelwerte wie image oder restart ersetzt die Override-Datei.
• Zuordnungen wie environment werden pro Schlüssel zusammengeführt.
• Listen wie ports oder extra_hosts werden ergänzt, nicht ersetzt.

Das Ergebnis zeigt docker compose config.

services:
  php:
    extra_hosts:
      - "id.dev.sonia.de:host-gateway"

  scheduler:
    extra_hosts:
      - "id.dev.sonia.de:host-gateway"

extra_hosts schreibt zusätzliche Einträge in die Datei /etc/hosts des Containers. Der Sonderwert host-gateway steht für die IP-Adresse des Docker-Hosts, also des eigenen Rechners. Im Container löst id.dev.sonia.de damit zum Rechner auf, auf dem der Keycloak-Proxy an Port 443 lauscht.

Betroffen sind nur php und scheduler, denn nur dort läuft PHP-Code. nginx spricht nie selbst mit Keycloak.

Lokal zeigt id.dev.sonia.de per /etc/hosts des Rechners auf 127.0.0.1. Für den Browser ist das richtig: Er läuft auf dem Rechner und erreicht dort den Keycloak-Proxy.

TYPO3 muss Keycloak aber auch selbst erreichen. Nach dem Login tauscht es den Code gegen Tokens, holt die Userinfo und lädt für den Back-Channel-Logout die Signaturschlüssel. In einem Container bedeutet 127.0.0.1 jedoch der Container selbst, und dort läuft kein Keycloak. Ohne die Override-Datei scheitert der Login mit einem Verbindungsfehler.

Der umgekehrte Weg braucht keinen Eintrag: Keycloak erreicht TYPO3 für den Back-Channel-Logout über host.docker.internal:8088, den Docker Desktop selbst bereitstellt.

# Variante 1: Datei weglassen bzw. löschen
rm docker-compose.override.yml

# Variante 2: nur die Hauptdatei verwenden
docker compose -f docker-compose.yml up -d

# Variante 3: dauerhaft in der .env festlegen
COMPOSE_FILE=docker-compose.yml

Auf einem Server mit echtem DNS löst id.dev.sonia.de ohnehin richtig auf. Der Eintrag wäre dort falsch, weil er Anfragen auf den Server selbst umleitet. Deshalb wird die Override-Datei dort nicht verwendet.

Umgekehrt ist sie der richtige Ort für weitere lokale Anpassungen, etwa einen anderen Kontext für ausführliche Fehlermeldungen:

services:
  php:
    environment:
      TYPO3_CONTEXT: Development