Entwicklungs- vs. Produktions-Compose: Trennung der Konfigurationen

In modernen Docker-Setups ist es unerlässlich, Entwicklungs- und Produktionsumgebungen klar zu trennen. Unterschiedliche Anforderungen an Logging, Debugging, Sicherheitsrichtlinien und Ressourcen machen es notwendig, separate Docker Compose-Dateien zu verwenden. In diesem Tutorial erfahren Sie, wie Entwicklungs- und Produktions-Compose konfiguriert, kombiniert und sicher betrieben werden können.

Warum Trennung wichtig ist

Die Anforderungen in Entwicklung und Produktion unterscheiden sich deutlich:

  • Entwicklung: Debugging, Hot-Reload, umfangreiche Logs, Testdaten
  • Produktion: Sicherheitsrichtlinien, Ressourcenlimits, minimale Logs, stabile Versionen
  • Ohne Trennung besteht das Risiko, dass Debug-Features oder ungesicherte Ports produktiv laufen
  • Rollback und Updates können in der Produktion komplexer werden

Basis-Compose-Datei

Eine gemeinsame Basis-Datei docker-compose.base.yml kann die gemeinsamen Services und Netzwerke definieren:

version: "3.9"

services:
  web:
    image: myorg/web:1.0.0
    networks:
      - frontend
  api:
    image: myorg/api:2.0.0
    networks:
      - backend

networks:
  frontend:
  backend:
  • Vermeidet Redundanz in mehreren Compose-Dateien
  • Basisdefinition kann von Development- und Production-Overlays erweitert werden

Entwicklungs-Compose

In der Entwicklungsumgebung sind zusätzliche Features sinnvoll:

version: "3.9"

services:
  web:
    build: .
    volumes:
      - ./src:/app/src
    environment:
      - DEBUG=true
    ports:
      - "3000:3000"
    depends_on:
      - api
  api:
    build: ./api
    environment:
      - DEBUG=true
    ports:
      - "5000:5000"
    volumes:
      - ./api/src:/app/src
  • Hot-Reload durch Mounting von lokalen Verzeichnissen
  • Debugging aktiviert via Environment Variables
  • Exponierte Ports für lokale Tests

Produktions-Compose

In Produktion sollten Images stabil, minimiert und abgesichert sein:

version: "3.9"

services:
  web:
    image: myorg/web:1.0.0
    environment:
      - DEBUG=false
    deploy:
      replicas: 3
      resources:
        limits:
          cpus: "1.0"
          memory: "512M"
      restart_policy:
        condition: on-failure
    ports:
      - "80:80"
    secrets:
      - db_password
  api:
    image: myorg/api:2.0.0
    environment:
      - DEBUG=false
    deploy:
      replicas: 2
      resources:
        limits:
          cpus: "0.5"
          memory: "256M"
      restart_policy:
        condition: on-failure
    secrets:
      - api_key

secrets:
  db_password:
    external: true
  api_key:
    external: true
  • Keine Debug-Funktionen
  • Ressourcenlimits für CPU und RAM
  • Secrets für sensible Daten statt Environment Variables
  • Skalierung via Replicas

Überlagerung von Compose-Dateien

Docker Compose erlaubt das Zusammenführen mehrerer Dateien:

docker-compose -f docker-compose.base.yml -f docker-compose.dev.yml up -d
docker-compose -f docker-compose.base.yml -f docker-compose.prod.yml up -d
  • Die zweite Datei überschreibt bzw. ergänzt die Basisdefinition
  • Ermöglicht konsistente Struktur zwischen Entwicklung und Produktion
  • Reduziert Duplikation und Fehlerquellen

Netzwerk- und Portmanagement

Trennung der Netzwerke sorgt für Sicherheit:

  • Frontend-Netzwerk für öffentlich zugängliche Services
  • Backend-Netzwerk für interne Services wie Datenbanken
  • Ports in Produktion nur minimal nach außen öffnen
  • In Entwicklung können zusätzliche Ports für Debugging offen sein

Best Practices für Trennung

  • Versionierte und stabile Images in Produktion
  • Secrets statt Environment Variables für sensible Daten
  • Separate Compose-Dateien für Development und Production
  • Healthchecks für produktive Services implementieren
  • Ressourcenlimits in Produktion setzen
  • Rollback-Strategien planen
  • Monitoring und Logging anpassen an die Umgebung
  • Automatisierte Tests in Development, Staging vor Produktion

Beispiel für Blue-Green Deployment mit getrennten Compose-Dateien

# Blue (aktive Version)
docker-compose -f docker-compose.base.yml -f docker-compose.prod.blue.yml up -d

Green (neue Version zum Testen)

docker-compose -f docker-compose.base.yml -f docker-compose.prod.green.yml up -d

  • Blue-Umgebung bedient aktuellen Traffic
  • Green-Umgebung wird getestet
  • Traffic wird bei Erfolg auf Green umgeleitet
  • Blue dient als Rollback

Monitoring und Logging

Entwicklungs- und Produktionsumgebungen unterscheiden sich bei Logging:

  • Development: ausführliche Logs, Debug-Informationen, Hot-Reload
  • Production: zentrale Logs, minimale Ausgaben, Healthchecks
  • Monitoring-Tools wie Prometheus, Grafana oder ELK können beide Umgebungen unterstützen

Zusammenfassung

Die Trennung von Entwicklungs- und Produktions-Compose-Dateien ist essenziell für sichere, stabile und wartbare Docker-Umgebungen. Basis-Compose-Dateien minimieren Redundanz, während Entwicklungsdateien Debugging, Hot-Reload und Testfeatures aktivieren. Produktionsdateien setzen auf stabile Images, Ressourcenlimits, Secrets und Healthchecks. Überlagerung von Compose-Dateien erlaubt konsistente Deployments und erleichtert Rollouts sowie Rollbacks.

Konfiguriere Cisco Router & Switches und liefere ein Packet-Tracer-Lab/GNS3

Ich biete professionelle Unterstützung im Bereich Netzwerkkonfiguration und Network Automation für private Anforderungen, Studienprojekte, Lernlabore, kleine Unternehmen sowie technische Projekte. Ich unterstütze Sie bei der Konfiguration von Routern und Switches, der Erstellung praxisnaher Topologien in Cisco Packet Tracer, dem Aufbau und Troubleshooting von GNS3- und EVE-NG-Labs sowie bei der Automatisierung von Netzwerkaufgaben mit Netmiko, Paramiko, NAPALM und Ansible. Kontaktieren Sie mich jetzt – klicken Sie hier.

Meine Leistungen umfassen:

  • Professionelle Konfiguration von Routern und Switches

  • Einrichtung von VLANs, Trunks, Routing, DHCP, NAT, ACLs und weiteren Netzwerkfunktionen

  • Erstellung von Topologien und Simulationen in Cisco Packet Tracer

  • Aufbau, Analyse und Fehlerbehebung von Netzwerk-Labs in GNS3 und EVE-NG

  • Automatisierung von Netzwerkkonfigurationen mit Python, Netmiko, Paramiko, NAPALM und Ansible

  • Erstellung von Skripten für wiederkehrende Netzwerkaufgaben

  • Dokumentation der Konfigurationen und Bereitstellung nachvollziehbarer Lösungswege

  • Konfigurations-Backups, Optimierung bestehender Setups und technisches Troubleshooting

Benötigen Sie Unterstützung bei Ihrem Netzwerkprojekt, Ihrer Simulation oder Ihrer Network-Automation-Lösung? Kontaktieren Sie mich jetzt – klicken Sie hier.

Related Articles