Die Container innerhalb von Docker kommunizieren über interne Netzwerke ( networks) miteinander. Ich habe sie schon oft innerhalb docker-compose.yml benutzt, aber nie richtig erklärt.
docker networks
Über die networks kommuniziert ein Container mit dem Host, anderen Containern oder nur sich selbst. Das hängt vom jeweiligen Driver ab.
Driver
die verschiedenen Driver sind
- host – hiermit wird die Isolation zum Hostnetzwerk aufgehoben und der Container benutzt dann die IP-Adresse des Hosts. Hier sind keine Portfreigaben nötig, dadurch kann u.U. zu Kollisionen kommen.
- none – Der Container hat keine Netzwerkschnitstelle und ist komplett isoliert.
- bridge – Dies ist der Default Driver. Der Container bekommt einen eigenen IP-Bereich und ist über eine Brücke docker0 mit dem Host verbunden. Ports müssen manuell gemapped werden.
- overlay – ein virtuelles Netzwerk über mehrere Hosts hinweg. Dadurch können rechenintensive Container oder Container mit Hochverfügbarkeit auf mehrere Hosts verteilt werden.
- macvlan – Der Container erhält seine eigene MAC und IP im LAN.
- ipvlan – Ist ähnlich zu macvlan, alle Container teilen ich die IP-Adresse des Hostsystems.
Dieses Driver stellt docker unter Linux bereit. Für spezielle Anforderungen lässt sich die Liste erweitern.
vorhandene Netzwerke auflisten
Mit dem Kommando
docker network lskannst du dir die vorhandenen networks ansehen. Bei einer frischen Dockerinstallation ohne laufende Container, erhalte ich diese Liste
Diese drei networks bilden die Grundlage für die Containernetworks.
Auf meinem Nextcloud Raspi ist die Liste etwas umfangreicher.
Zusätzlich zu den System Netzwerken gibt es hier noch die networks gitea_default und nextcloud_default mit dem bridge Driver. Diese werden bei Erzeugung des Containers angelegt, wenn in der docker-compose.yml kein explizites Netzwerk mit networks: angefordert wird.
Das bridge network nextcloud_nextcloudnet wurde für die Kommunikation zwischen den Containern Nextcloud Cron und Redis erzeugt.
network inspizieren
Es lassen sich ganz einfach Informationen zu einem network abrufen
docker network inspect nextcloud_nextcloudnetDabei wird ein JSON-Objekt mit allen Informationen geliefert. Zwecks besserer Lesbarkeit kopiere ich das Ergebnis mal komplett hier rein.
[
{
"Name": "nextcloud_nextcloudnet",
"Id": "4d46a984faf84bacf2724f3b03445c70d99783be1b640dad4c44fd88c60312b8",
"Created": "2025-08-15T09:03:38.411665603+02:00",
"Scope": "local",
"Driver": "bridge",
"EnableIPv6": false,
"IPAM": {
"Driver": "default",
"Options": null,
"Config": [
{
"Subnet": "172.19.0.0/16",
"Gateway": "172.19.0.1"
}
]
},
"Internal": false,
"Attachable": true,
"Ingress": false,
"ConfigFrom": {
"Network": ""
},
"ConfigOnly": false,
"Containers": {
"47316f2829b54c5c0ecde3dc6d15dd0547f1a379f5e2669db1a86acd7af15b0e": {
"Name": "redis",
"EndpointID": "c97e0dd4e89c71aedf0c7b1d8b3bac71d04e448e5bd836082d7b6fc72fe23311",
"MacAddress": "02:42:ac:13:00:02",
"IPv4Address": "172.19.0.2/16",
"IPv6Address": ""
},
"536c8fac1a01d0afb4137e5f1f984b8241842938eb52ac7ebc5b18b0417cb2af": {
"Name": "nextcloud-cron",
"EndpointID": "e4ca3d308d52eabd36720bcb18e62bee0f6910a1b8b6a3391640a8ee78210d38",
"MacAddress": "02:42:ac:13:00:04",
"IPv4Address": "172.19.0.4/16",
"IPv6Address": ""
},
"fccef785b5e34f05376ff556293191728b44b8e3a4b1b80ee7ffe1b24e40229a": {
"Name": "nextcloud",
"EndpointID": "cb66c4371f27369a7ecd56778fcf995030c9a7db256502bffb383155d93e114f",
"MacAddress": "02:42:ac:13:00:03",
"IPv4Address": "172.19.0.3/16",
"IPv6Address": ""
}
},
"Options": {},
"Labels": {
"com.docker.compose.network": "nextcloudnet",
"com.docker.compose.project": "nextcloud",
"com.docker.compose.version": "1.29.2"
}
}
]
Du findest hier nicht nur die Angaben mit dem Zeitpunkt der Erzeugung des Netzwerks und dem verwendeten Driver. Auch alle Container, die dieses Netzwerk nutzen, sind hier aufgelistet. Letzteres ist gerade dann interessant, wenn du analysieren willst, ob ein Netzwerk noch notwendig ist.
Interessant ist, dass dem Namen des network als Präfix ein „nextcloud_“ automatisch vorangestellt wurde. Warum das so ist, konnte ich nicht genau ergründen. Ich vermute allerdings, dass beim initialen Aufsetzen von Nextcloud, der nextcloud Container der erste im .yml war, der das Netzwerk benutzte. Andere Containerdeklarationen sind erst später dazu gekommen und da war der Name mit Präfix bereits festgelegt.
network manuell anlegen
Du kannst ein network auch von Hand erzeugen. Dazu benutzt du den Befehl
docker network create -d bridge testnetworkDas Netzwerk existiert dann völlig losgelöst von einem Container. Mit dem -d Parameter spezifizierst du den Driver des Netzwerks.
Mit docker inspect schau ich mir mal an, wie testnetwork konfiguriert wurde.
[
{
"Name": "testnetwork",
"Id": "b054c4ea0869349fb77e7d1aea2a8d8d7c3b8a15c2d7194189f6061433c13909",
"Created": "2026-01-20T09:48:19.474730291+01:00",
"Scope": "local",
"Driver": "bridge",
"EnableIPv6": false,
"IPAM": {
"Driver": "default",
"Options": {},
"Config": [
{
"Subnet": "172.21.0.0/16",
"Gateway": "172.21.0.1"
}
]
},
"Internal": false,
"Attachable": false,
"Ingress": false,
"ConfigFrom": {
"Network": ""
},
"ConfigOnly": false,
"Containers": {},
"Options": {},
"Labels": {}
}
]
Klar zu erkennen ist hier, dass intern der IP-Adressraum 172.21.0.0.0 verwendet wird, der über die bridge nach außen abgebildet wird.
Netzwerk manuell löschen
Genauso kannst du mit dem Befehl
docker network rm testnetworkdas eben erzeugte Netzwerk wieder löschen. Hierbei solltest du vorsichtig sein! Es erfolgt keine Sicherheitsabfrage, wenn du ein network, dass an Container gebunden ist, gelöscht werden soll.
Fazit
Über docker Netzwerke kommunizieren Container mit der Aussenwelt oder untereinander.
