Einheitliche Docker-Umgebung durch globale Daemon-Einstellungen

Einheitliche Docker-Umgebung durch globale Daemon-Einstellungen

Egal ob lokal oder auf dem Server – bei Docker tauchen immer wieder dieselben Konfigurationen in den docker-compose.yml-Dateien auf.

• DNS immer auf 1.1.1.1, 8.8.8.8 setzen
• Log‑Treiber auf json-file + max-size=10m festlegen
• Proxy, insecure registry, Standard‑Netzwerk‑Bereich usw.

Diese Einstellungen lassen sich besser als Host‑weite Standardwerte in der Docker‑Daemon‑Konfiguration (daemon.json) zentralisieren.

Im Folgenden erkläre ich:

• Welche Datei
• Wo sie liegt
• Wie sie geschrieben wird
• Für wen sie besonders nützlich ist

1. Zwei Wege, den Docker‑Daemon zu konfigurieren

Der Docker‑Daemon (dockerd) lässt sich auf zwei Arten konfigurieren:

1. JSON‑Datei (daemon.json) – empfohlen
2. CLI‑Flags beim Start von dockerd

Man kann beide Methoden kombinieren, aber gleiche Optionen in beiden Stellen führen dazu, dass der Daemon nicht startet. Beispiel: --log-driver in der Flag‑Liste und in daemon.json gleichzeitig.

Für eine einheitliche Team‑/Server‑Umgebung empfiehlt sich daher:

„Sammle so viele Optionen wie möglich in daemon.json und halte die Flags minimal.“

2. Wo befindet sich daemon.json?

Die Standard‑Standorte je nach Betriebssystem und Installationsmethode lassen sich in einer Tabelle zusammenfassen:

• Die Datei existiert nicht immer – bei Bedarf einfach anlegen.
• Für Team‑/Server‑Standards wird meist die Linux‑Version /etc/docker/daemon.json als Referenz verwendet.

3. Standard‑Workflow: „Datei erstellen → Daemon neu starten“

Der häufigste Ablauf unter Linux:

1. daemon.json anlegen oder bearbeiten

{
  "dns": ["1.1.1.1", "8.8.8.8"],
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  }
}

2. Vorschau‑Validierung

sudo dockerd --validate --config-file=/etc/docker/daemon.json
# Wenn "configuration OK" erscheint, ist alles in Ordnung

3. Docker‑Daemon neu starten

sudo systemctl restart docker

Ab diesem Zeitpunkt erben neue Container die globalen Einstellungen, sofern sie nicht explizit überschrieben werden.

4. Beispiel 1 – DNS‑Server global festlegen

4.1 Warum global?

Wenn Container häufig Probleme wie „API nicht erreichbar“ oder „interne Domain nicht auflösbar“ melden, liegt das meist an der DNS‑Konfiguration des Hosts.

Beispiel:

• Das gesamte Team möchte Cloudflare DNS (1.1.1.1) nutzen
• Interne Endpunkte sind nur über den firmeneigenen DNS‑Server erreichbar

In solchen Fällen ist es sinnvoller, die DNS‑Einstellungen im Daemon zu zentralisieren, anstatt sie in jeder docker-compose.yml zu wiederholen.

4.2 Konfigurationsbeispiel (daemon.json)

{
  "dns": ["1.1.1.1", "8.8.8.8"]
}

Falls bereits eine daemon.json existiert, füge das "dns": [...]-Element im obersten Objekt hinzu (Achtung: Komma‑Position).

⚠️ Hinweis: DNS‑Einstellungen werden in /etc/resolv.conf der Container übernommen. Bereits laufende Container werden nicht sofort aktualisiert – die Änderungen wirken erst bei neuen Containern.

4.3 Für wen ist das nützlich?

• Entwickler in Unternehmen mit Proxy oder internem DNS
• Plattform‑Teams, die in Multi‑Cloud‑Umgebungen einen festen DNS‑Server erzwingen müssen
• Einzelpersonen, die lokal zwischen mehreren VPN‑Verbindungen wechseln

5. Beispiel 2 – Log‑Treiber & Optionen global festlegen

Container‑Logs werden standardmäßig mit dem json-file‑Treiber in /var/lib/docker/containers/... abgelegt. Durch globale Einstellungen kann man Format, Speicherort und Rotationspolitik für alle Container einheitlich steuern.

5.1 Standard‑json-file mit Rotation

{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "5"
  }
}

Damit hat jede Log‑Datei maximal 10 MB, werden maximal 5 Dateien behalten und überschüssige Logs werden automatisch gelöscht.

5.2 Zentrale Log‑Sammlung (z. B. Fluentd, journald)

Für Plattform‑ oder Infrastruktur‑Teams ist es oft sinnvoll, Logs an ein zentrales System zu senden. Beispiel mit Fluentd:

{
  "log-driver": "fluentd",
  "log-opts": {
    "fluentd-address": "localhost:24224",
    "tag": "{{.Name}}"
  }
}

Alle Container senden ihre Logs automatisch an Fluentd, ohne dass docker run --log-driver=… nötig ist.

journald ist ebenfalls beliebt, besonders in systemd‑basierten Linux‑Umgebungen, da man Logs über journalctl zentral verwalten kann:

{
  "log-driver": "journald",
  "log-opts": {
    "tag": "{{.Name}}"
  }
}

Dann kann man z. B. journalctl -f -t {container_name} nutzen, um Logs eines Containers in Echtzeit zu verfolgen.

5.3 Zusammenspiel mit Compose / docker run

• Globale log-driver + log-opts gelten als Standard.
• Container‑spezifische Einstellungen in Compose (logging:) oder CLI (--log-driver, --log-opt) überschreiben nur diesen Container.

Strategie: Gemeinsame Werte in daemon.json, spezielle Services individuell überschreiben.

6. Beispiel 3 – Proxy, insecure registry und weitere Netzwerk‑Einstellungen

6.1 Proxy‑Konfiguration

Wenn ein Unternehmen ausschließlich über einen Proxy erreichbar ist, kann man die Proxy‑Einstellungen im Daemon festlegen:

{
  "proxies": {
    "http-proxy": "http://proxy.example.com:3128",
    "https-proxy": "http://proxy.example.com:3128",
    "no-proxy": "localhost,127.0.0.1,.corp.example.com"
  }
}

Docker nutzt diese Proxy‑Einstellungen beim Pullen von Images oder beim Build.

6.2 insecure registry

Für nicht‑TLS‑Registries (z. B. interne Test‑Registry):

{
  "insecure-registries": ["my-registry.local:5000"]
}

Verwendung nur in internen Test‑Umgebungen, da Sicherheitsrisiken bestehen.

7. Beispiel 4 – Standard‑Bridge‑Netzwerk‑Bereich, Storage‑Treiber usw.

7.1 Standard‑Bridge‑Netzwerk‑Bereich anpassen

Um IP‑Konflikte mit VPN‑Netzwerken zu vermeiden:

{
  "default-address-pools": [
    {
      "base": "10.20.0.0/16",
      "size": 24
    }
  ]
}

Docker verwendet dann 10.20.x.0/24 für neue Bridge‑Netzwerke.

7.2 Storage‑Treiber erzwingen

Je nach Linux‑Distribution kann der Standard‑Storage‑Treiber variieren. Wenn das Team ausschließlich overlay2 nutzen möchte:

{
  "storage-driver": "overlay2"
}

Prüfe die Kompatibilität mit dockerd‑Dokumentation und deiner Distribution.

8. Wer profitiert besonders?

8.1 Einzelentwickler

• Wiederholte Verwendung derselben Docker‑Optionen in mehreren Projekten
• Häufig wechselnde VPN‑/Proxy‑Umgebungen
• Lokale Log‑ und Speicherverwaltung

→ Mit einer einzigen daemon.json erhält man ein konsistentes Setup.

8.2 Kleine bis mittlere Teams

• Unterschiedliche lokale Docker‑Konfigurationen führen zu „funktioniert auf meinem PC, nicht auf deinem“
• CI‑Server und Entwickler‑Umgebungen sollen möglichst identisch sein
• Unternehmens‑Standards für DNS, Proxy, Registry

→ Definiere die Team‑Regeln in daemon.json und verteile die Datei z. B. über Ansible, Chef, Terraform oder Cloud‑Init.

8.3 Plattform‑Teams / DevOps / SRE

• Verwaltung von Hunderten von Containern auf mehreren Nodes
• Einheitliche Log‑, Storage‑ und Netzwerk‑Politiken
• Standardisierung von Sicherheits‑ und Monitoring‑Richtlinien auf Host‑Ebene

→ daemon.json wird zur zentralen Richtliniendatei für Docker‑Nodes.

9. Debug‑Tipps

1. Flags vs. daemon.json - Prüfe die systemd‑Unit (/lib/systemd/system/docker.service) auf vorhandene Flags. - Gleiche Optionen in beiden Stellen führen zum Startfehler.
2. Docker Desktop - Änderungen über die GUI werden intern in ~/.docker/daemon.json gespeichert. - Vermeide doppelte Änderungen – konsolidiere die Einstellungen an einer Stelle.

Fazit

• Globale Docker‑Einstellungen werden in daemon.json verwaltet.
• Standard‑Pfad: Linux → /etc/docker/daemon.json.
• Typische Optionen: DNS, Log‑Treiber, Proxy, insecure registry, Netzwerk‑Bereich, Storage‑Treiber.
• Für Einzelentwickler, Teams und Plattform‑Teams bietet die zentrale Konfiguration erhebliche Vorteile in Bezug auf Konsistenz und Wartbarkeit.

Wenn du immer wieder dieselben Optionen in docker-compose.yml oder docker run wiederholst, ist jetzt der richtige Zeitpunkt, sie in daemon.json zu verschieben.