Prämisse:
Ich versuche, mich zusammenzureißenjüngste Lernenüber Netzwerkschnittstellen und Ports und versuchen Sie, das neu Gelernte mit Docker zu verknüpfen.
Eine kurze Zusammenfassung der Dinge, die ich im Zusammenhang mit dieser Frage gelernt habe:
- Jeder Computer kann mehrere IP-Adressen haben, eine für jede Netzwerkschnittstelle.
- IP-Adressen werden Schnittstellen zugewiesen, nicht Computern usw.
- Ein Socket ist ein IP+Port.
- DHCP ist häufig/wahrscheinlich das, was einer Schnittstelle eine IP-Adresse zuweist.
Wie bei vielen Aspekten der Arbeit mit Software mache ich die Dinge zunächst nach dem „Ritual“, das ich lerne, weil „es so gemacht wird“. Dann, mit der Zeit und Erfahrung, fange ich an, über das Warum und Weshalb nachzudenken und es zu untersuchen. Daher möchte ich dieses neue Wissen mit Docker verknüpfen.
Das „Ritual“, das ich gelernt habe, ist, dass, wenn eine containerisierte Anwendung an einem TCP-Socket lauscht, man den Port dieses Sockets „freigeben“ muss, damit der Verkehr, der an einer der Schnittstellen des Hosts an diesem Port ankommt, an den Container „weitergeleitet“ wird. Richten Sie die Dinge
beispielsweise docker run -d -p 81:80 httpd
so ein, dass, wenn ich meinen Webbrowser auf 127.0.0.81 richte, der HTTP/TCP/IP-Verkehr an denhttpdPort 80 des Containers.
Wenn ich also meinen Webbrowser auf 127.0.0.1:81 richte, wird mir die Apache-Meldung „Es funktioniert!“ angezeigt.
Aber auch: wenn ich meinen Webbrowser auf 127.0.0 richte.2:81 oder 127.0.0.16:81, dann sehe ich auch die Meldung „Es funktioniert!“ von Apache.
Wie ich aus den verlinkten Beiträgen erfahren habe, hat DHCP der Schnittstelle meiner Netzwerkkarte die IP-Adresse 10.0.0.17 zugewiesen, und wenn ich meinen Webbrowser auf 10.0.0.17:81 richte, wird mir auch hier die Apache-Meldung „Es funktioniert!“ angezeigt.
Es funktioniert auch, wenn ich den Webbrowser eines anderen PCs im selben Netzwerk auf 10.0.0.17:81 richte.
Frage:
Meine primäreFragelautet: Für welche Schnittstellen (IP-Adressen) des Host-PCs werden Ports vom Host zum Container weitergeleitet, wenn Sie dies docker run
mit dem -p
Argument tun? Nach der angemerkten Beobachtung scheint die Antwort „alle Schnittstellen“ zu sein – ist das der Fall?
Aber allgemeiner: Welche Beziehung besteht zwischen Schnittstellen und Ports zwischen einem Host-PC und einem Docker-Container?
Was ich versucht habe
Ich habe versucht, den docker run
Hilfetext zu lesen, aber der Text -p
ist nicht auf einem Niveau, auf dem ich ihn mit den Fragen in Verbindung bringen kann, die ich stelle:
-p, --publish list Port(s) eines Containers auf dem Host veröffentlichen
Ich habe versucht, ifconfig
im Kontext meines PCs und des laufendenhttpdContainer.
ifconfig
auf Host-PC:
$ ifconfig
docker0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 172.17.0.1 netmask 255.255.0.0 broadcast 172.17.255.255
inet6 fe80::42:caff:fe23:f0f4 prefixlen 64 scopeid 0x20<link>
ether 02:42:ca:23:f0:f4 txqueuelen 0 (Ethernet)
RX packets 3079 bytes 322688 (322.6 KB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 6429 bytes 15942682 (15.9 MB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1000 (Local Loopback)
RX packets 17975 bytes 1557651 (1.5 MB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 17975 bytes 1557651 (1.5 MB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
wlp1s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 10.0.0.17 netmask 255.255.255.0 broadcast 10.0.0.255
inet6 fe80::5f8c:c301:a6a3:6e35 prefixlen 64 scopeid 0x20<link>
ether f8:59:71:01:89:cf txqueuelen 1000 (Ethernet)
RX packets 1672559 bytes 2237440808 (2.2 GB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 726083 bytes 113598143 (113.5 MB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
ifconfig
im RennenhttpdContainer (ich habe ihn mit installiert apt-get
):
# ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 172.17.0.3 netmask 255.255.0.0 broadcast 172.17.255.255
ether 02:42:ac:11:00:03 txqueuelen 0 (Ethernet)
RX packets 1326 bytes 8916833 (8.5 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 1134 bytes 76866 (75.0 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
loop txqueuelen 1000 (Local Loopback)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
Wenn man diese Frage im Kontext der obigen ifconfig
Ausgabe betrachtet, welche Beziehung besteht zwischen diesen Schnittstellen auf dem Host-PC und den Schnittstellen im Docker-Container?
VonHier, meines Wissens hat DHCP der Netzwerkkarte auf meinem Host-PC die Adresse 10.0.0.17 zugewiesen. Aber woher kommt die Adresse 172.17.0.3?
Antwort1
[NB: Sie scheinen hier drei Fragen zu haben, von denen mindestens eine zu allgemein ist, um eine klare, akzeptable Antwort zu haben. Im Allgemeinen funktioniert SuperUser am besten, wenn Sie pro Fragenbeitrag nur eine eng definierte Frage stellen.]
Meine Hauptfrage lautet: Für welche Schnittstellen (IP-Adressen) des Host-PCs werden Ports vom Host zum Container weitergeleitet, wenn Sie Docker Run mit dem Argument -p ausführen? Laut der angemerkten Beobachtung scheint die Antwort „alle Schnittstellen“ zu sein – ist das der Fall?
Ja.
Aber allgemeiner: Welche Beziehung besteht zwischen Schnittstellen und Ports zwischen einem Host-PC und einem Docker-Container?
Dies ist ein bisschen zu allgemein, um es gut beantworten zu können, ohne Sie auf die Netzwerkdokumentation von Docker zu verweisen. Docker enthält viele verschiedene Netzwerkoptionen, die die Beziehungen zwischen Schnittstellen und Ports zwischen Host-PCs und Docker-Containern ändern. Es ist sehr flexibel.
Aber woher kommt die 172.17.0.3?
Dockers Standard-Netzwerkmodus,Brückennetzwerke, erstellt eine Softwarebrücke (wie ein virtueller Ethernet-Switch) auf dem Host und verbindet die Container über virtuelle Netzwerkschnittstellen damit. Wie ein kleines virtuelles Ethernet-LAN, alles innerhalb des Hosts. Anschließend verwendet es NAT (ähnlich wie ein Home-Gateway-Router), damit Ihre Container das Netzwerk jenseits des Hosts erreichen können. Das NAT verwendet das Subnetz 172.17.0.0/16 als sein privates Subnetz.
Docker verwendet dieses Subnetz, da es Teil des privaten Adressraums RFC 1918 ist, genau wie 192.168.0.0/16, 10.0.0.0/8 und der Rest von 172.16.0.0/12.
Es scheint, dass Docker die Container programmgesteuert mit statischen Adressen in diesem Subnetz konfiguriert (DHCP würde die Dinge unnötig verkomplizieren).