Begriff

Docker Compose Networks

Containerization Networking S2

2 Quellen 1 Lernpfad 1 Backlink enriched

Warum wichtig?

Dieser Begriff ist ein Knoten im SengakujiWorks-Wissensnetz. Nutze Level 0 für die erste Einordnung, Level 1 für Praxis, Level 2 für technische Struktur und Level 3 für Grenzen, Fallstricke und Expertenkontext.

Früher (mit docker run) musste man Container manuell verbinden (--link). Das war schrecklich. Docker Compose macht das automatisch. Wenn du eine docker-compose.yml startest, erstellt Docker ein neues, isoliertes Netzwerk für dieses Projekt. Der Projektname ist oft der Ordnername (z. B. myapp_default). Alle Container in dieser Datei landen in diesem Netzwerk. Sie können sich gegenseitig beim Namen rufen: web kann db anpingen. Aber Container aus einem anderen Projekt (otherapp_default) kommen nicht rein. Das ist gut für Sicherheit und Ordnung.

Merksatz: Die automatische Netzwerkkonfiguration in Docker Compose, die applikations-spezifische Bridge-Netzwerke erstellt und DNS-Namen basierend auf Service-Namen bereitstellt.

Standardmäßig musst du gar nichts konfigurieren. Aber manchmal willst du spezielle Netzwerke.

services:
  frontend:
    networks:
      - public  # Darf nach außen
      - internal # Darf zur DB

  backend:
    networks:
      - internal # Darf NICHT direkt angesprochen werden

networks:
  public:
  internal:
    internal: true # Kein Internetzugriff (Isolation)

Hier baust du eine DMZ (Demilitarized Zone). Das Frontend ist der Gatekeeper. Das Backend ist geschützt.

Praxisroutine

In der Praxis lernst du Docker Compose Networks, indem du mit einem kleinen, kontrollierten Beispiel beginnst. Baue zuerst einen Minimalfall, prüfe das Ergebnis, veraendere genau eine Sache und beobachte, was sich ändert. Notiere dir Eingabe, Aktion, Ausgabe und typischen Fehler.

Übung: Erstelle ein Beispiel aus deinem Alltag, fuehre den Ablauf gedanklich Schritt für Schritt durch und markiere die Stelle, an der du Feedback oder ein Log brauchst. Wenn du diese Stelle benennen kannst, verstehst du den Begriff praktisch.

1. External Networks

Wenn du Microservices in getrennten Compose-Files hast. app-a/docker-compose.yml und app-b/docker-compose.yml. Wie reden sie miteinander? Du definierst ein shared network.

networks:
  global-net:
    external: true

Docker meckert nicht "Network not found", sondern sucht ein bereits existierendes Netzwerk namens global-net. Beide Apps hängen sich rein und können sich pingen.

2. Aliases & Priority

Was, wenn ich db heißen will, aber der Service heißt database_postgres_v14?

services:
  db:
    networks:
      default:
        aliases:
          - postgres
          - database

Jetzt antwortet der DNS auf alle drei Namen. Wichtig bei Migrationen ("Mock-Database" soll so heißen wie die echte).

3. Driver Opts (MTU)

Ein häufiger Fehler in VPNs oder OpenStack Clouds: Die MTU (Maximum Transmission Unit, Paketgröße) ist kleiner als 1500. Docker Bridge standardmäßig 1500. Folge: Große Pakete werden gedroppt -> "SSH geht, aber HTTPS hängt". Lösung:

networks:
  default:
    driver_opts:
      com.docker.network.driver.mtu: 1400

DNS Round Robin & Service Skalierung

Was passiert, wenn du in Compose sagst: deploy: replicas: 3 für den web-Service? Docker Compose erstellt drei Container (project_web_1, project_web_2, project_web_3). Aber der interne eingebettete DNS-Server tut nun etwas Brillantes: DNS Round Robin. Wenn die API ping web aufruft, gibt der DNS beim ersten Mal die IP von Container 1 zurück, dann die von Container 2, etc. (Round Robin Load Balancing). Achtung: Dies ist Client-Side Load Balancing. Wenn deine Anwendung DNS-Antworten starr im RAM cached (z. B. manche ältere Java oder Node.js Konfigurationen), wird der Traffic hart an einen einzigen Container gebunden, und die Skalierung bringt exakt gar nichts.

IP Overlaps & das VPN-Problem

Docker Compose verteilt IPs aus dem 172.17.x.x oder 172.18.x.x Adressraum (RFC 1918). Wenn du für eine große Firma im VPN arbeitest, kann es passieren, dass das Firmen-Router-VPN exakt dieses Subnetz routet. Ergebnis: Du tippst ping firmenserver (172.18.0.5) und pingst versehentlich deinen lokalen Redis-Container in Compose. Die lokale Bridge ("Connected Route") schlägt die VPN-Route im Kernel. Lösung in Compose: Du musst das Subnetz von Compose hart umbiegen (z. B. auf abstruse IPs wie 10.254.x.x).

networks:
  default:
    ipam:
      config:
        - subnet: 10.254.1.0/24

Macvlan in Compose (Raw Layer 2)

Braucht dein Container eine echte DHCP-IP aus dem LAN deines physischen Routers (z. B. FritzBox)? (Oft für Smart Home wie HomeAssistant oder PiHole). Hierbei versagt Bridge, da es NAT nutzt. Compose unterstützt den Macvlan-Treiber.

networks:
  lan:
    driver: macvlan
    driver_opts:
      parent: eth0 # Das physische Interface des Hosts

Der Container hängt nun effektiv "physikalisch" am Router. Das Tückische ("Macvlan 802.1q Limitation"): Aus Sicherheitsgründen im Linux-Kernel kann der Host-Server seinen eigenen Macvlan-Container nun nicht mehr anpingen! Die Kommunikation zwischen Host und Container ist abgeschnitten, während das restliche LAN fehlerfrei kommuniziert.

Quick-Check

Gehen Ports (80:80) durch das Netzwerk?
Nein. Ports (ports) mappen vom Host in den Container. Das Netzwerk verbindet Container untereinander. Für Container-zu-Container Kommunikation brauchst du keine Ports öffnen! Nur für Host-zu-Container.
Was ist host.docker.internal?
Ein spezieller DNS-Name (auf Mac/Windows), damit der Container den Host erreichen kann ("Localhost vom Host"). Unter Linux standardmäßig nicht da (muss man mit extra_hosts enabled).
Warum "Project Name"?
Compose präfixiert alles mit dem Ordnernamen (myproject_network). Damit kannst du das gleiche Projekt 2x im gleichen Docker Daemon starten (in 2 Ordnern), ohne dass die Netze kollidieren.