Docker stellt mit dem standardmäßigen Bridge-Netzwerk eine grundlegende Möglichkeit bereit, Container miteinander und mit externen Netzwerken zu verbinden. Für einfache Anwendungen genügt diese Konfiguration häufig. Sobald jedoch mehrere zusammengehörende Dienste betrieben werden, sind eine gezielte Netzwerkzuordnung, die automatische Namensauflösung und die Trennung unterschiedlicher Anwendungsbereiche von Vorteil.
Benutzerdefinierte Docker-Netzwerke ermöglichen es, Container unabhängig vom Standardnetzwerk in eigene Netzwerkbereiche einzugruppieren. Container innerhalb eines solchen Netzwerks können sich über ihre Namen erreichen, während die direkte Kommunikation mit Containern anderer Bridge-Netzwerke standardmäßig eingeschränkt ist. Einzelne Container lassen sich bei Bedarf auch mit mehreren Netzwerken verbinden.
Dieser Artikel erläutert die Einrichtung und Verwaltung benutzerdefinierter Bridge-Netzwerke, untersucht die Kommunikation zwischen Containern und zeigt, wie Netzwerkverbindungen im laufenden Betrieb hinzugefügt oder entfernt werden können. Die Beispiele bauen auf den Grundlagen der Docker-Container-Netzwerke auf und verwenden eine bestehende Docker-Installation unter Linux.
Benutzerdefinierte Bridge-Netzwerke erstellen
Neben dem automatisch vorhandenen Standardnetzwerk bridge lassen sich mit Docker beliebig viele benutzerdefinierte Netzwerke anlegen. Für zusammengehörende Container empfiehlt sich ein eigenes Bridge-Netzwerk, dessen Name sich an der jeweiligen Anwendung oder Funktion orientiert.
Ein neues Netzwerk wird mit docker network create erstellt:
$ sudo docker network create academy-net-01
48723e8dc02025f0c63ef7aed16956407d6bf758991a8c656aebe40df947a3ccDocker verwendet ohne zusätzliche Optionen den Netzwerktreiber bridge und weist dem Netzwerk automatisch einen freien IP-Adressbereich einschließlich Gateway zu. Bei erfolgreicher Ausführung gibt der Befehl die eindeutige Netzwerk-ID zurück.
$ sudo docker network ls
NETWORK ID NAME DRIVER SCOPE
48723e8dc020 academy-net-01 bridge local
dd70b5cc9abc bridge bridge local
3107afeded6f host host local
08db602fa7d1 none null localIn der Spalte NAME erscheinen die Namen der Docker-Netzwerke, während DRIVER den verwendeten Netzwerktreiber angibt. Das neu angelegte Netzwerk academy-net-01 und das Standardnetzwerk bridge verwenden denselben Treiber, sind aber zwei eigenständige Netzwerke.
Die vollständige Konfiguration eines Netzwerks kann mit docker network inspect untersucht werden:
$ sudo docker network inspect academy-net-01
[
{
"Name": "academy-net-01",
"Id": "48723e8dc02025f0c63ef7aed16956407d6bf758991a8c656aebe40df947a3cc",
"Created": "2026-11-01T19:23:40.15776848+01:00",
"Scope": "local",
"Driver": "bridge",
"EnableIPv4": true,
"EnableIPv6": false,
"IPAM": {
"Driver": "default",
"Options": {},
"Config": [
{
"Subnet": "172.18.0.0/16",
"Gateway": "172.18.0.1"
}
]
},
"Internal": false,
"Attachable": false,
"Ingress": false,
"ConfigFrom": {
"Network": ""
},
"ConfigOnly": false,
"Options": {},
"Labels": {},
"Containers": {},
"Status": {
"IPAM": {
"Subnets": {
"172.18.0.0/16": {
"IPsInUse": 3,
"DynamicIPsAvailable": 65533
}
}
}
}
}
]Der Abschnitt IPAM (IP Address Management) enthält die Adresskonfiguration. Im Beispiel vergibt Docker das Subnetz 172.18.0.0/16 mit dem Gateway 172.18.0.1. IPv4 ist aktiviert, IPv6 für dieses Docker-Netzwerk dagegen deaktiviert. Das Feld Containers ist unmittelbar nach dem Erstellen leer, da noch kein Container angeschlossen wurde.
Die zugehörige Linux-Bridge
Für jedes benutzerdefinierte Bridge-Netzwerk richtet Docker eine eigene Linux-Bridge auf dem Host ein. Während das Standardnetzwerk die bekannte Schnittstelle docker0 verwendet, erhalten benutzerdefinierte Netzwerke normalerweise einen Namen nach dem Schema br- gefolgt von den ersten zwölf Zeichen ihrer Netzwerk-ID.
Die vorhandenen Linux-Bridge-Schnittstellen lassen sich anzeigen:
$ ip -br addr show type bridge
docker0 UP 172.17.0.1/16 fe80::e875:50ff:fe8a:6103/64
br-48723e8dc020 DOWN 172.18.0.1/16Die Ausgabe zeigt zwei voneinander getrennte Linux-Bridges mit jeweils eigenem IP-Adressbereich. Die neue Bridge besitzt bereits ihre Gateway-Adresse, befindet sich jedoch noch im Zustand DOWN, da kein aktiver Container mit ihr verbunden ist.
Sobald ein laufender Container an das Netzwerk angeschlossen wird, erstellt Docker das zugehörige veth-Paar und verbindet dessen Host-Ende mit der neuen Bridge. Bei einer aktiven Verbindung wechselt die Bridge normalerweise in den Zustand UP.
Die Bezeichnungen der Linux-Bridges müssen nicht mit den Namen der Docker-Netzwerke übereinstimmen. Für die reguläre Verwaltung werden die logischen Netzwerknamen verwendet (hier: academy-net-01); die technischen Schnittstellennamen sind vor allem bei der Diagnose auf Host-Ebene relevant.
Container mit benutzerdefinierten Netzwerken verbinden
Ein Container kann bereits beim Erstellen einem bestimmten Docker-Netzwerk zugeordnet werden. Dazu dient die Option --network des Befehls docker run.
Für die folgenden Beispiele werden zwei Alpine-Linux-Container verwendet, die mit dem zuvor erstellten Netzwerk academy-net-01 verbunden werden:
$ sudo docker run -d \
--name academy-cont-alpine-01 \
--network academy-net-01 \
alpine sleep infinity$ sudo docker run -d \
--name academy-cont-alpine-02 \
--network academy-net-01 \
alpine sleep infinityDie Option --network academy-net-01 legt fest, welchem Netzwerk Docker den jeweiligen Container beim Start zuordnet. Mit -d werden die Container im Hintergrund gestartet. Der Befehl sleep infinity hält sie für die Netzwerkexperimente dauerhaft am Leben, ohne einen zusätzlichen Dienst bereitzustellen.
Beide Container erhalten automatisch eine IP-Adresse aus dem Adressbereich 172.18.0.0/16. Im Beispiel verwendet academy-cont-alpine-01 die Adresse 172.18.0.2 und academy-cont-alpine-02 die Adresse 172.18.0.3.
Netzwerkzuordnung überprüfen
Die Netzwerkkonfiguration eines Containers lässt sich mit docker inspect auslesen. Um ausschließlich die Netzwerkverbindungen übersichtlich darzustellen, kann die JSON-Ausgabe mit jq formatiert werden:
$ sudo docker inspect --format '{{json .NetworkSettings.Networks}}' academy-cont-alpine-02 | jq
{
"academy-net-01": {
"IPAMConfig": {},
"Links": null,
"Aliases": [],
"DriverOpts": {},
"GwPriority": 0,
"NetworkID": "48723e8dc02025f0c63ef7aed16956407d6bf758991a8c656aebe40df947a3cc",
"EndpointID": "f2da6d80b94f80a9484d2881148f4465104dbf2c7de769796e745fb8cc01681f",
"Gateway": "172.18.0.1",
"IPAddress": "172.18.0.3",
"MacAddress": "76:ac:c9:ec:2a:fb",
"IPPrefixLen": 16,
"IPv6Gateway": "",
"GlobalIPv6Address": "",
"GlobalIPv6PrefixLen": 0,
"DNSNames": [
"academy-cont-alpine-02",
"0cd27e968505"
]
}
}Die Ausgabe enthält unter dem Netzwerknamen academy-net-01 die zugehörigen Parameter, beispielsweise die Netzwerk-ID, IP-Adresse, MAC-Adresse und das Gateway.
Der Netzwerkname bildet dabei den Schlüssel des JSON-Objekts. Die langen Netzwerk- und Endpoint-IDs dienen der eindeutigen Identifikation, während für die reguläre Administration die lesbaren Docker-Namen verwendet werden können.
Eine kompakte Übersicht der Netzwerke, mit denen ein Container verbunden ist, liefert:
$ sudo docker inspect \
--format '{{json .NetworkSettings.Networks}}' \
academy-cont-alpine-02 | jq -r 'keys[]'
academy-net-01Im Beispiel erscheint ausschließlich academy-net-01, da der Container momentan keinem weiteren Netzwerk angehört. Auch innerhalb des Containers lässt sich die Netzwerkzuordnung überprüfen:
$ sudo docker exec academy-cont-alpine-02 ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
---snip---
3: eth0@if39: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue state UP
link/ether 76:ac:c9:ec:2a:fb brd ff:ff:ff:ff:ff:ff
inet 172.18.0.3/16 brd 172.18.255.255 scope global eth0
---snip---Neben der Loopback-Schnittstelle lo besitzt der Container die Schnittstelle eth0 mit der Adresse 172.18.0.3/16. In der Ausgabe erscheint diese als eth0@if39. Die Zahl 39 bezeichnet den Schnittstellenindex des zugehörigen veth-Gegenstücks auf dem Docker-Host. Dort lässt sich die Verbindung mit ip -o link show nachvollziehen:
$ ip -o link
---snip---
39: veth0c15d86@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-48723e8dc020 state UP mode DEFAULT group default \ link/ether aa:1e:36:79:27:9e brd ff:ff:ff:ff:ff:ff link-netnsid 5Die Angabe master br-48723e8dc020 bestätigt, dass das Host-Ende des veth-Paares mit der Linux-Bridge des benutzerdefinierten Netzwerks verbunden ist. Die Schnittstellenindizes und veth-Namen werden dynamisch vergeben und können sich nach dem erneuten Verbinden eines Containers ändern.
Damit verfügen beide Container über eine gemeinsame Netzwerkverbindung und können direkt miteinander kommunizieren, ohne dass dafür Host-Ports veröffentlicht werden müssen.
Automatische Namensauflösung und Container-Kommunikation
Ein wesentlicher Unterschied zwischen dem standardmäßigen Docker-Netzwerk bridge und benutzerdefinierten Bridge-Netzwerken ist die integrierte DNS-Namensauflösung.
Während Container im Standardnetzwerk ohne zusätzliche Konfiguration nur über ihre IP-Adressen miteinander kommunizieren können, lassen sich Container innerhalb eines benutzerdefinierten Netzwerks direkt über ihre Namen erreichen. Docker verwaltet die entsprechenden DNS-Einträge automatisch.
Der integrierte Docker-DNS-Resolver
In benutzerdefinierten Netzwerken stellt Docker einen DNS-Resolver unter der Adresse 127.0.0.11 bereit. Die Konfiguration lässt sich innerhalb eines Containers überprüfen:
$ sudo docker exec academy-cont-alpine-02 cat /etc/resolv.conf
---snip---
nameserver 127.0.0.11
search fritz.box
options ndots:0
---snap---Obwohl 127.0.0.11 eine Loopback-Adresse ist, handelt es sich nicht um einen eigenständigen DNS-Dienst, der als Prozess innerhalb des Containers läuft. Docker stellt den DNS-Endpunkt im jeweiligen Network Namespace bereit, während die eigentliche Resolver-Funktionalität von der Docker Engine übernommen wird.
Da jeder Container seinen eigenen Network Namespace besitzt, können mehrere Container dieselbe Loopback-Adresse verwenden, ohne dass ein Adresskonflikt entsteht.
Der Resolver beantwortet Anfragen nach bekannten Containernamen innerhalb der gemeinsam verwendeten Docker-Netzwerke. Andere DNS-Anfragen können an die konfigurierten externen Resolver weitergeleitet werden.
Namensauflösung und Erreichbarkeit überprüfen
Die Namensauflösung lässt sich mit nslookup überprüfen:
$ sudo docker exec academy-cont-alpine-01 nslookup academy-cont-alpine-02.
Server: 127.0.0.11
Address: 127.0.0.11:53
Non-authoritative answer:
Non-authoritative answer:
Name: academy-cont-alpine-02
Address: 172.18.0.3Der abschließende Punkt kennzeichnet den Namen als absoluten DNS-Namen und verhindert, dass eine vorhandene DNS-Suchdomain angehängt wird.
Im Beispiel wird die Adresse 172.18.0.3 zurückgegeben. Docker kennt somit die Netzwerkadresse des zweiten Containers, ohne dass ein manueller DNS-Eintrag erforderlich ist.
Für einen kombinierten Test aus Namensauflösung und Netzwerkerreichbarkeit eignet sich ping:
$ sudo docker exec academy-cont-alpine-01 ping -c 3 academy-cont-alpine-02
PING academy-cont-alpine-02 (172.18.0.3): 56 data bytes
64 bytes from 172.18.0.3: seq=0 ttl=64 time=0.043 ms
64 bytes from 172.18.0.3: seq=1 ttl=64 time=0.175 ms
64 bytes from 172.18.0.3: seq=2 ttl=64 time=0.183 msDer Containername wird erfolgreich aufgelöst und alle drei ICMP-Echo-Requests werden beantwortet. Die Kommunikation erfolgt direkt über die gemeinsame Linux-Bridge. Eine Veröffentlichung von Container-Ports auf dem Docker-Host ist dafür nicht erforderlich.
Die Namensauflösung erleichtert insbesondere den Betrieb mehrerer zusammengehörender Dienste. Beispielsweise kann eine Anwendung eine PostgreSQL-Datenbank über den Namen postgres und den Port 5432 ansprechen, sofern beide Container mit demselben benutzerdefinierten Netzwerk verbunden sind und die Datenbank unter diesem Namen erreichbar ist.
Ändert sich die IP-Adresse des Datenbankcontainers bei einer Neuerstellung, kann Docker die Namensauflösung entsprechend aktualisieren. Die Anwendung muss deshalb keine fest hinterlegte Container-IP-Adresse verwenden.
Die automatische Namensauflösung ist jedoch keine Zugriffskontrolle. Sie erleichtert das Auffinden anderer Container, während die tatsächliche Erreichbarkeit von der Netzwerkzuordnung und den geltenden Netzwerkregeln abhängt.
Netzwerkisolation zwischen Bridge-Netzwerken
Benutzerdefinierte Bridge-Netzwerke dienen nicht nur der Organisation zusammengehörender Container, sondern ermöglichen auch eine gezielte Trennung unterschiedlicher Anwendungsbereiche.
Docker richtet für jedes benutzerdefinierte Bridge-Netzwerk eine eigene Linux-Bridge ein und konfiguriert Firewall-Regeln, die eine direkte Kommunikation zwischen verschiedenen Bridge-Netzwerken standardmäßig unterbinden.
Im bisherigen Beispiel existieren zwei getrennte Netzwerke: Das standardmäßige Netzwerk bridge mit dem Subnetz 172.17.0.0/16 und das benutzerdefinierte Netzwerk academy-net-01 mit 172.18.0.0/16.
Während die beiden Alpine-Testcontainer mit academy-net-01 verbunden sind, befinden sich die bereits vorhandenen nginx-Container im Standardnetzwerk.
Kommunikation zwischen den Netzwerken überprüfen
Um die Trennung zu überprüfen, wird aus academy-cont-alpine-01 versucht, den nginx-Container unter seiner internen IP-Adresse 172.17.0.3 zu erreichen:
$ sudo docker exec academy-cont-alpine-01 wget -T 3 -qO- http://172.17.0.3:80
wget: download timed outObwohl beide Netzwerke auf demselben Linux-Host existieren und der Kernel grundsätzlich zwischen ihren Subnetzen routen könnte, verhindern die von Docker eingerichteten Filterregeln die direkte Kommunikation. Die Netzwerkisolation beruht somit nicht allein auf den unterschiedlichen IP-Adressbereichen. Entscheidend sind die zusätzlich eingerichteten Regeln für den Netzwerkverkehr.
Die Trennung ist allerdings keine vollständige Sicherheitsabschottung. Beispielsweise können über veröffentlichte Host-Ports weiterhin Zugriffswege zu Containern anderer Netzwerke bestehen. Auch ausgehende Verbindungen in externe Netzwerke sind bei gewöhnlichen Bridge-Netzwerken standardmäßig möglich.
Benutzerdefinierte Netzwerke schaffen daher eine sinnvolle Grundlage für die Segmentierung containerisierter Anwendungen, ersetzen aber keine umfassende Firewall- und Sicherheitskonfiguration.
Empfehlung für die Praxis
Für neue Docker-Anwendungen empfiehlt sich grundsätzlich die Verwendung benutzerdefinierter Bridge-Netzwerke anstelle des automatisch vorhandenen Standardnetzwerks bridge.
Dadurch lassen sich zusammengehörende Container gezielt gruppieren, voneinander unabhängige Anwendungen trennen und einheitliche Regeln für die Namensauflösung und Netzwerkzuordnung verwenden. Dies erleichtert insbesondere die Administration, Dokumentation, Fehlersuche und spätere Migrationen.
Auch Docker Compose folgt diesem Konzept: Sofern keine abweichende Konfiguration vorliegt, erstellt Compose für ein Projekt automatisch ein eigenes benutzerdefiniertes Netzwerk. Die beteiligten Dienste können sich darin über ihre Servicenamen erreichen.
Container mit mehreren Netzwerken verbinden
Ein Docker-Container kann gleichzeitig mehreren Netzwerken angehören. Dadurch lässt sich beispielsweise ein Anwendungsserver sowohl mit einem Frontend-Netzwerk als auch mit einem getrennten Datenbanknetzwerk verbinden, ohne dass alle beteiligten Container demselben Netzwerk angehören müssen.
Docker ermöglicht es, einem bereits laufenden Container zusätzliche Netzwerkverbindungen zuzuweisen. Dazu dient der Befehl docker network connect.
Eine zusätzliche Netzwerkverbindung herstellen
Der bisher ausschließlich mit academy-net-01 verbundene Container academy-cont-alpine-01 wird zusätzlich an das standardmäßige Bridge-Netzwerk angeschlossen:
$ sudo docker network connect bridge academy-cont-alpine-01Im Beispiel besitzt der Container anschließend zwei Netzwerkschnittstellen:
$ sudo docker exec academy-cont-alpine-01 ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
---snip---
2: eth0@if34: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue state UP
link/ether 76:dc:0b:41:3a:97 brd ff:ff:ff:ff:ff:ff
inet 172.18.0.2/16 brd 172.18.255.255 scope global eth0
---snip---
4: eth1@if40: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue state UP
link/ether 9a:17:28:cd:78:e8 brd ff:ff:ff:ff:ff:ff
inet 172.17.0.6/16 brd 172.17.255.255 scope global eth1
---snip---Damit ist eth0 weiterhin mit academy-net-01 verbunden, während eth1 die Verbindung zum Standardnetzwerk bridge herstellt.
Routing bei mehreren Netzwerkverbindungen
Mit einer zusätzlichen Netzwerkschnittstelle erhält der Container auch eine weitere Route. Die Routingtabelle lässt sich folgendermaßen untersuchen:
$ sudo docker exec academy-cont-alpine-01 ip route
default via 172.18.0.1 dev eth0
172.17.0.0/16 dev eth1 scope link src 172.17.0.6
172.18.0.0/16 dev eth0 scope link src 172.18.0.2Beide direkt angeschlossenen Netzwerke besitzen eine eigene Route. Pakete in das Subnetz 172.17.0.0/16 werden über eth1 übertragen, während das Subnetz 172.18.0.0/16 über eth0 erreichbar ist.
Die Default-Route verweist im Beispiel weiterhin auf das Gateway 172.18.0.1. Bei mehreren angeschlossenen Netzwerken kann die Auswahl des Standardgateways durch Docker beeinflusst werden, unter anderem über die Gateway-Priorität gw-priority.
Kommunikation mit dem zweiten Netzwerk überprüfen
Nach dem zusätzlichen Netzwerkanschluss wird der zuvor fehlgeschlagene Zugriff auf den nginx-Container wiederholt:
$ sudo docker exec academy-cont-alpine-01 wget -T 3 -qO- http://172.17.0.3:80
<!DOCTYPE html>
<html lang="de">
<head>
<meta charset="UTF-8">
<title>Docker Lernprojekt</title>
</head>
---snip---Diesmal liefert der Webserver erfolgreich seine HTML-Seite zurück. Der Zugriff funktioniert, weil academy-cont-alpine-01 inzwischen selbst mit dem Standardnetzwerk verbunden ist und das Ziel direkt über eth1 erreichen kann.
Der zweite Alpine-Container academy-cont-alpine-02 bleibt dagegen ausschließlich mit academy-net-01 verbunden. Für ihn ist der nginx-Container weiterhin nicht direkt erreichbar.
Ein Container mit zwei Netzwerkanschlüssen wird dadurch nicht automatisch zu einem Router zwischen den angeschlossenen Netzwerken. Dafür wären unter anderem passende Routinginformationen und die zulässige Weiterleitung der Pakete erforderlich.
Die Mehrfachanbindung ermöglicht somit eine gezielte Kommunikation mit verschiedenen Netzwerkbereichen, ohne die übrigen Container ebenfalls mit diesen Netzwerken verbinden zu müssen.
Netzwerkverbindungen im laufenden Betrieb verwalten
Docker ermöglicht es, die Netzwerkzuordnung eines laufenden Containers zu verändern, ohne ihn dafür stoppen oder neu erstellen zu müssen. Neben docker network connect steht dazu der Befehl docker network disconnect zur Verfügung.
Dies ist beispielsweise hilfreich, wenn Container einem anderen Netzwerk zugeordnet, vorübergehend vom Netzwerk getrennt oder bestehende Netzwerkverbindungen entfernt werden sollen.
Einen Container vom Netzwerk trennen
Der Container academy-cont-alpine-02 ist zunächst ausschließlich mit academy-net-01 verbunden. Seine einzige Netzwerkverbindung wird mit folgendem Befehl entfernt:
$ sudo docker network disconnect academy-net-01 academy-cont-alpine-02Docker entfernt daraufhin den zugehörigen Netzwerk-Endpoint und das veth-Paar. Der Container selbst bleibt jedoch in Betrieb, da sein laufender Prozess sleep infinity keine Netzwerkverbindung benötigt.
Die verbleibenden Netzwerkverbindungen lassen sich mit docker inspect überprüfen:
$ sudo docker inspect --format '{{json .NetworkSettings.Networks}}' academy-cont-alpine-02 | jq
{}Auch innerhalb des Containers ist die Veränderung sichtbar:
$ sudo docker exec academy-cont-alpine-02 ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
---snip---
inet6 ::1/128 scope host
---snip---Die bisherige Schnittstelle eth0 ist verschwunden. Lediglich die Loopback-Schnittstelle lo mit den Adressen 127.0.0.1/8 und ::1/128 bleibt erhalten.
Der Container besitzt damit weiterhin einen eigenen Network Namespace, aber keine Verbindung zu einem Docker-Bridge-Netzwerk mehr. Seine Netzwerkanbindung entspricht in diesem Zustand weitgehend der eines Containers, der mit --network none gestartet wurde.
Netzwerkverbindung wiederherstellen
Mit docker network connect kann der laufende Container erneut mit dem ursprünglichen Netzwerk verbunden werden:
$ sudo docker network connect academy-net-01 academy-cont-alpine-02Docker erstellt dafür ein neues veth-Paar und verbindet es mit der Linux-Bridge br-48723e8dc020. Der Container erhält wieder eine Schnittstelle eth0 sowie eine Adresse aus dem Subnetz 172.18.0.0/16.
Im Beispiel wird erneut die IP-Adresse 172.18.0.3 vergeben. Gleichzeitig ändern sich jedoch die MAC-Adresse, der veth-Name und die Schnittstellenindizes, da Docker eine neue Netzwerkverbindung erstellt.
Die erneute Vergabe derselben IP-Adresse ist nicht garantiert. Anwendungen sollten deshalb möglichst die automatische Docker-Namensauflösung verwenden, anstatt sich auf unveränderliche Container-IP-Adressen zu verlassen.
Das Hinzufügen oder Entfernen von Netzwerkverbindungen verändert somit die Netzwerkanbindung eines Containers, ohne zwangsläufig dessen laufende Prozesse zu beeinflussen. Bestehende Netzwerkverbindungen und darauf angewiesene Anwendungen können durch eine Trennung allerdings unmittelbar unterbrochen werden.
Fazit
Benutzerdefinierte Bridge-Netzwerke ermöglichen eine übersichtliche und gezielte Vernetzung von Docker-Containern. Sie verwenden jeweils eine eigene Linux-Bridge und bieten gegenüber dem standardmäßigen Bridge-Netzwerk insbesondere die automatische DNS-Namensauflösung sowie eine bessere Trennung unterschiedlicher Anwendungsbereiche.
Container innerhalb eines gemeinsamen Netzwerks können direkt über ihre Namen miteinander kommunizieren, ohne dass dafür Ports auf dem Docker-Host veröffentlicht werden müssen. Die direkte Kommunikation zwischen unterschiedlichen Bridge-Netzwerken ist dagegen standardmäßig eingeschränkt. Bei Bedarf können einzelne Container mehreren Netzwerken zugeordnet werden.
Mit docker network connect und docker network disconnect lassen sich Netzwerkverbindungen auch während des laufenden Containerbetriebs verändern. Dabei bleiben die Containerprozesse grundsätzlich erhalten, während Docker die erforderlichen Netzwerkschnittstellen dynamisch erstellt oder entfernt.
Für neue Docker-Anwendungen sind benutzerdefinierte Netzwerke daher dem automatisch vorhandenen Standardnetzwerk in der Regel vorzuziehen. Sie erleichtern die Administration und bilden eine wichtige Grundlage für die strukturierte Vernetzung und Segmentierung containerisierter Anwendungen.
Befehlsreferenz
| Befehl | Funktion |
|---|---|
docker network create NAME | Benutzerdefiniertes Netzwerk erstellen |
docker network ls | Vorhandene Docker-Netzwerke auflisten |
docker network inspect NAME | Netzwerkkonfiguration und angeschlossene Container anzeigen |
docker run --network NAME ... | Container beim Erstellen einem Netzwerk zuordnen |
docker network connect NETZWERK CONTAINER | Laufenden Container mit einem weiteren Netzwerk verbinden |
docker network disconnect NETZWERK CONTAINER | Netzwerkverbindung eines Containers entfernen |
docker inspect CONTAINER | Containerkonfiguration einschließlich Netzwerkverbindungen ausgeben |
docker exec CONTAINER ip addr | Netzwerkschnittstellen innerhalb eines Containers anzeigen |
docker exec CONTAINER ip route | Routingtabelle innerhalb eines Containers anzeigen |
docker exec CONTAINER cat /etc/resolv.conf | DNS-Konfiguration innerhalb eines Containers anzeigen |
Die Docker-Befehle benötigen entsprechende Berechtigungen auf dem Docker-Host und werden in den Beispielen mit sudo ausgeführt.
