Container-Netzwerke
Die wichtigsten Befehle zum Merken
docker network ls— Netzwerkobjekte und Treiber finden.docker network inspect— Adressen und angeschlossene Container prüfen.docker ps— laufende Container mit Portabbildungen vergleichen.
Befehle und Optionen
| Befehl oder Option | Bedeutung |
|---|---|
docker network ls |
Netzwerke der gewählten Engine auflisten. |
docker network inspect bridge |
Das vorhandene Standard-Bridge-Netzwerk prüfen. |
--format '{{json .IPAM.Config}} {{json .Containers}}' |
Adresskonfiguration und angeschlossene Container als JSON zeigen. |
docker ps --format 'table …' |
Namen, Netzwerke und Portinformationen tabellarisch ausgeben. |
{{.Names}}, {{.Networks}}, {{.Ports}} |
Docker-Templatefelder, keine Shellvariablen. |
Tabulatoren trennen Spalten. Der Docker-Kontext wählt die Engine. Unter Docker Desktop läuft die Linux-Engine normalerweise in einer VM.
Die entscheidenden Konzepte
1. Ein Container kann eine eigene Netzwerkansicht haben
Ein typischer Linux-Container-Netzwerknamespace besitzt eigene Schnittstellen, Adressen, Routen und Portbindungen. Loopback bezeichnet diesen Namespace, nicht automatisch Host oder Nachbarcontainer.
Zwei isolierte Container können beide Port 8080 verwenden. Konflikte entstehen bei gleicher Adresse und gleichem Port im gemeinsamen Namespace oder bei identischem veröffentlichtem Host-Endpunkt. Host-Network-Modus verändert diese Annahmen.
2. Eine Bridge verbindet Containerschnittstellen
Ein Bridge-Netzwerk verbindet teilnehmende Interfaces über die Engine. Containeradressen gehören zu diesem Netzwerk; Routen und Regeln bestimmen weitere Ziele.
Die Adresse ist nicht zwingend direkt vom Laptop erreichbar, besonders bei einer Engine in einer VM. Ausgehender Verkehr kann Adressübersetzung nutzen. Prüfe den Treiber, statt jedem Container pauschal eine Bridge zu unterstellen.
3. Dienstnamen und Adressen erfüllen verschiedene Aufgaben
Benutzerdefinierte Docker-Bridges bieten automatische DNS-Auflösung zwischen ihren Containern. Namen vermeiden die Abhängigkeit von Adressen, die sich bei Neuerstellung ändern können.
Die Standard-Bridge bietet nicht dieselbe automatische Container-Namensauflösung. Erfolgreiches DNS beweist außerdem weder einen Listener noch erlaubten Verkehr. Namensauflösung, Routing, Filter und Anwendung bleiben getrennte Schritte.
4. Portveröffentlichung schafft einen Host-Einstieg
Ein veröffentlichter Port bildet eine Hostadresse samt Port auf einen Containerport ab. Das unterscheidet sich von einer bloßen Portdeklaration im Image.
Die Bindung zählt: Nur Loopback und alle Hostinterfaces haben verschiedene Reichweite. Auch die Anwendung muss an einer passenden Containeradresse lauschen. Eine Abbildung erzeugt keinen fehlenden Listener und überstimmt nicht jede externe Firewall.
Ein kleines Beispiel
Optional: Untersuche die gewählte Testengine. Die Befehle lesen nur Konfiguration, erstellen keine Netzwerke und veröffentlichen keine Ports. Befehl zwei setzt die normale Linux-Standard-Bridge voraus.
docker network ls
docker network inspect bridge --format '{{json .IPAM.Config}} {{json .Containers}}'
docker ps --format 'table {{.Names}} {{.Networks}} {{.Ports}}'Prüfe Treiber, Subnetz und angeschlossene Container. Ohne Teilnehmer ist ein leeres Objekt normal. Container anderer Netzwerke erscheinen nicht in dieser Anschlussliste.
Vergleiche zuletzt reine Containerportangaben mit Abbildungen samt Hostadresse und Pfeil zum Containerport. Formate können variieren. Die Prüfung sendet keinen Verkehr und beweist weder DNS noch externe Erreichbarkeit. Fehlt bridge in einer angepassten Engine, ist das ein anderer Aufbau, kein Beweis defekter Vernetzung.
Merke dir: Container-Netzwerke verbinden getrennte Netzwerkansichten. Namen, Routen, Listener und Hostports lösen verschiedene Teile der Erreichbarkeit.