Docker Netzwerke erklärt: bridge, host & eigene Netze

Warum erreicht ein Container die Datenbank nicht, obwohl beide laufen? Meist liegt es am Netzwerk. Dieser Artikel erklärt Docker Netzwerke von Grund auf: Welche Netzwerktypen es gibt, wie du eigene Netze anlegst, Container über ihren Namen verbindest und wann du Ports nach außen freigeben musst. So verstehst du Docker Netzwerke nicht nur oberflächlich, sondern kannst Container-Kommunikation, DNS-Auflösung und Port-Veröffentlichung gezielt steuern und typische Verbindungsprobleme selbst lösen.

Welche Netzwerktypen gibt es?

Docker bringt mehrere Netzwerk-Treiber mit. Diese drei sind im Alltag am wichtigsten:

Daneben gibt es none (kein Netzwerk) und overlay (für Container über mehrere Hosts hinweg, etwa im Swarm). Für ein einzelnes Homelab-System reichen bridge und host fast immer aus.

Der wichtige Unterschied: Default-Bridge vs. eigenes Netzwerk

Startest du Container ohne Angabe eines Netzwerks, landen sie im Default-Bridge-Netz. Dort erreichen sie sich nur über IP-Adressen – unpraktisch, weil sich diese ändern können. Legst du dagegen ein eigenes (user-defined) Netzwerk an, aktiviert Docker eine automatische DNS-Auflösung: Container erreichen sich dann einfach über ihren Namen. Das ist der Hauptgrund, warum du für zusammengehörige Dienste immer ein eigenes Netzwerk nutzen solltest.

Ein eigenes Netzwerk anlegen

Ein benutzerdefiniertes Bridge-Netzwerk erstellst du mit einem einzigen Befehl:

docker network create mein-netz

docker network create mein-netz

Danach startest du Container in diesem Netz über den Parameter --network:

docker run -d --name datenbank --network mein-netz postgres:16
docker run -d --name app --network mein-netz meine-app:latest

docker run -d --name datenbank --network mein-netz postgres:16
docker run -d --name app --network mein-netz meine-app:latest

Container über den Namen verbinden

Weil beide Container im selben eigenen Netz hängen, erreicht die App die Datenbank jetzt einfach unter dem Hostnamen datenbank – ganz ohne IP-Adresse. In der App-Konfiguration nutzt du also z. B.:

DATABASE_HOST=datenbank
DATABASE_PORT=5432

DATABASE_HOST=datenbank
DATABASE_PORT=5432

Docker löst den Namen datenbank automatisch zur richtigen internen IP auf. Ändert sich diese, funktioniert die Verbindung trotzdem weiter.

Netzwerke in docker-compose

In Compose erstellt Docker automatisch ein gemeinsames Netzwerk für alle Dienste eines Stacks – die DNS-Auflösung über den Servicenamen funktioniert dort also von Haus aus. Du kannst aber auch eigene Netze definieren:

services:
  app:
    image: meine-app:latest
    networks:
      - frontend
      - backend
  datenbank:
    image: postgres:16
    networks:
      - backend

networks:
  frontend:
  backend:

services:
  app:
    image: meine-app:latest
    networks:
      - frontend
      - backend
  datenbank:
    image: postgres:16
    networks:
      - backend

networks:
  frontend:
  backend:

So trennst du sauber: Die Datenbank hängt nur im backend, die App vermittelt zwischen frontend und backend. Die Grundlagen dazu findest du in Docker Compose installieren.

Ports veröffentlichen vs. interne Kommunikation

Ein häufiges Missverständnis: Du musst Ports nur dann mit -p veröffentlichen, wenn ein Dienst von außerhalb (vom Host oder aus dem Internet) erreichbar sein soll. Die Kommunikation zwischen Containern im selben Netz läuft ohne veröffentlichte Ports.

• Nach außen: -p 8080:80 macht Port 80 des Containers auf Host-Port 8080 erreichbar.
• Intern: Container im selben Netz erreichen sich direkt über den Container-Port – hier ist keine Veröffentlichung nötig.

Für den Zugriff aus dem Internet solltest du Dienste ohnehin nicht direkt freigeben, sondern über einen Reverse Proxy leiten – etwa den Nginx Proxy Manager.

Nützliche Netzwerk-Befehle

Netzwerk-Isolation als Sicherheitsvorteil

Eigene Netzwerke sind nicht nur bequem, sie erhöhen auch die Sicherheit. Container in getrennten Netzen können sich schlicht nicht sehen. Damit trennst du zum Beispiel eine Datenbank sauber vom öffentlich erreichbaren Webdienst: Die Datenbank liegt nur im internen backend-Netz und veröffentlicht keinen einzigen Port nach außen, während der Reverse Proxy im frontend-Netz die einzige Brücke ins Internet bildet.

• Vergib pro Anwendung ein eigenes Netz statt alles in die Default-Bridge zu hängen.
• Datenbanken und Caches gehören in ein rein internes Netz ohne -p-Portfreigabe.
• Setze das Flag --internal, wenn ein Netz gar keinen Zugang zum Internet erhalten soll.

Häufige Verbindungsprobleme beheben

Wenn zwei Container sich nicht erreichen, liegt es fast immer an einer von drei Ursachen. Erstens: Sie hängen in unterschiedlichen Netzwerken – prüfe das mit docker network inspect NETZ. Zweitens: Die Namensauflösung funktioniert in der Default-Bridge nicht, du brauchst ein eigenes Netzwerk. Drittens: Der Dienst lauscht im Container nur auf 127.0.0.1 statt auf 0.0.0.0 und ist deshalb von außen nicht erreichbar.

bridge, host oder macvlan – die richtige Wahl

Für die allermeisten Setups ist ein benutzerdefiniertes bridge-Netz die richtige Antwort. Den host-Modus nutzt du nur, wenn ein Dienst maximale Netzwerk-Performance braucht oder sehr viele Ports belegt – dafür verzichtest du auf jede Isolation. macvlan ist die Spezialoption, wenn ein Container wie ein eigenständiges Gerät mit eigener IP im LAN erscheinen soll, etwa für einen Pi-hole-DNS-Server.

Häufige Fragen

Warum erreichen sich meine Container nicht über den Namen?

Weil sie vermutlich in der Default-Bridge laufen. Dort gibt es keine automatische DNS-Auflösung. Lege ein eigenes Netzwerk mit docker network create an und starte beide Container darin – dann klappt die Verbindung über den Container-Namen.

Muss ich Ports veröffentlichen, damit zwei Container kommunizieren?

Nein. Container im selben Netzwerk erreichen sich direkt über den internen Port. -p brauchst du nur, wenn ein Dienst vom Host oder aus dem Internet erreichbar sein soll.

Wie verbinde ich einen laufenden Container mit einem weiteren Netz?

Mit docker network connect NETZ CONTAINER hängst du einen bereits laufenden Container zusätzlich in ein Netzwerk, ohne ihn neu erstellen zu müssen. Trennen geht mit docker network disconnect.

Fazit

Das Wichtigste in Kürze: Lege für zusammengehörige Container ein eigenes Bridge-Netzwerk an, dann funktioniert die Kommunikation komfortabel über Namen. Veröffentliche Ports nur dort, wo Zugriff von außen nötig ist. Damit vermeidest du die häufigsten Verbindungsprobleme. Passend weiter geht es mit Docker Volumes und dem Aufräumen ungenutzter Ressourcen.