Nachdem wir nun schon einige Artikel zum Thema Docker haben, wollen wir uns heute das Thema Docker Network mal genauer anschauen.
Inhaltsverzeichnis
Docker Network Arten
Bei docker werden im wesentlichen vier Netzwerkarten unterschieden:
- Closed Network / none Network
- Bridge Network
- Host Network
- Overlay Network
Diese vier Arten schauen wir uns nun nacheinander an.
Closed Network / none Network
Diese Docker Network Art wird verwendet, wenn der Docker Container keine Verbindung zu einem Netzwerk benötigt. Der Container bekommt keine Netzwerkkarte eingebaut und arbeitet isoliert von allen anderen Containern auf unserem Host. Man nennt diese dann auch closed container.
Wollen wir einen Container im ohne Netzwerk starten, dann kann man dies mit dem Parameter –net none. Der ganze Befehl sieht dann so aus:
1 2 | docker run -d --net none busybox sleep 1000 fe36b72b5ff0ab24a853cc1e3a34126f66fcf0b53196ea6bbd360b161b87945f |
Anschließend bauen wir eine Verbindung zum Container auf, schauen uns die Netzwerkkonfiguration an und versuchen Google zu pingen:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 | docker exec -it fe36b72b5ff0ab24a853cc1e3a34126f66fcf0b53196ea6bbd360b161b87945f /bin/ash / # ifconfig lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:65536 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) / # ping 8.8.8.8 PING 8.8.8.8 (8.8.8.8): 56 data bytes ping: sendto: Network is unreachable / # |
Wie man in der Ausgabe sieht, gibt es lediglich ein Loopback Interface und kein Interface was in einem Netzwerk hängt.
Vorteile:
- bietet das höchste Maß an Netzwerkschutz
- Geeignet, wenn der Container ein Höchstmaß an Netzwerksicherheit erfordert und kein Netzwerkzugriff erforderlich ist
Nachteile
- Keine gute Wahl, wenn eine Netzwerk- oder Internetverbindung erforderlich ist.
Bridge Network
Das Bridge Network ist das Standard Docker Network. Mit diesem Netzwerk können die Container untereinander und mit der Außenwelt kommunizieren.
Die Konfiguration des Bridge Network kann man sich mit docker network inspect bridge anzeigen lassen. Das ganze sieht dann wie folgt aus:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 | docker network inspect bridge [ { "Name": "bridge", "Id": "6628e646790ee97dcca2d32d0bc1c8cdb55ce5fbb854d71a800b0a3bd7d1c01b", "Created": "2018-05-31T07:51:43.531120929Z", "Scope": "local", "Driver": "bridge", "EnableIPv6": false, "IPAM": { "Driver": "default", "Options": null, "Config": [ { "Subnet": "172.17.0.0/16", "Gateway": "172.17.0.1" } ] }, "Internal": false, "Attachable": false, "Ingress": false, "ConfigFrom": { "Network": "" }, "ConfigOnly": false, "Containers": {}, "Options": { "com.docker.network.bridge.default_bridge": "true", "com.docker.network.bridge.enable_icc": "true", "com.docker.network.bridge.enable_ip_masquerade": "true", "com.docker.network.bridge.host_binding_ipv4": "0.0.0.0", "com.docker.network.bridge.name": "docker0", "com.docker.network.driver.mtu": "1500" }, "Labels": {} } ] |
Wenn wir nun einen Container starten und uns die Netzwerkkonfiguration anzeigen lassen, dann sehen wir das der Container automatisch eine IP im Bridged Network bekommen hat.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 | Christian @ ~ [17] → docker run -d --name first_container busybox sleep 1000 5c908cdab3202d80530d355632e08183481be8d3107217820f08d39563cd8469 Christian @ ~ [18] → docker exec -it first_container ifconfig eth0 Link encap:Ethernet HWaddr 02:42:AC:11:00:02 inet addr:172.17.0.2 Bcast:172.17.255.255 Mask:255.255.0.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:14 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:1156 (1.1 KiB) TX bytes:0 (0.0 B) lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:65536 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) |
Wenn wir jetzt einen zweiten Container starten, können wir von diesem den ersten Container pingen:
1 2 3 4 5 6 7 8 9 10 11 12 | Christian @ ~ [20] → docker run -d --name second_container busybox sleep 1000 5289680b8872ad94d8e8b46a8b366a3ae672a3771167e1985bf32f26df4cfa97 Christian @ ~ [21] → docker exec -it second_container ping 172.17.0.2 PING 172.17.0.2 (172.17.0.2): 56 data bytes 64 bytes from 172.17.0.2: seq=0 ttl=64 time=0.125 ms 64 bytes from 172.17.0.2: seq=1 ttl=64 time=0.067 ms 64 bytes from 172.17.0.2: seq=2 ttl=64 time=0.083 ms 64 bytes from 172.17.0.2: seq=3 ttl=64 time=0.071 ms 64 bytes from 172.17.0.2: seq=4 ttl=64 time=0.072 ms |
Das selbe Funktioniert nun auch in Richtung Google:
1 2 3 4 5 6 7 | Christian @ ~ [23] → docker exec -it second_container ping 8.8.8.8 PING 8.8.8.8 (8.8.8.8): 56 data bytes 64 bytes from 8.8.8.8: seq=0 ttl=37 time=23.830 ms 64 bytes from 8.8.8.8: seq=1 ttl=37 time=22.533 ms 64 bytes from 8.8.8.8: seq=2 ttl=37 time=23.201 ms 64 bytes from 8.8.8.8: seq=3 ttl=37 time=22.368 ms |
Vorteil
- Verbindung ins Internet
- Verbindung von Containern untereinander
Nachteil
- Reduzierung der Netzwerksicherheit
Host Network
Bei dieser Netzwerkart werden dem Docker Container die Netzwerkeigenschaften des Docker Hosts übertragen. Zum Starten eines Docker Containers im Host Network verwendet man den Parameter –net host. Das ganze sieht dann wie folgt aus.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 | Christian @ ~ [25] → docker run -d --name third_container --net host busybox sleep 1000 7e700a262f29047f5b2c53efda02462d8a4544e6c88324f921f13d2dbd7d4bb4 Christian @ ~ [26] → docker exec -it third_container ifconfig docker0 Link encap:Ethernet HWaddr 02:42:0D:87:F0:B6 inet addr:172.17.0.1 Bcast:172.17.255.255 Mask:255.255.0.0 inet6 addr: fe80::42:dff:fe87:f0b6/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:592 errors:0 dropped:0 overruns:0 frame:0 TX packets:605 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:47696 (46.5 KiB) TX bytes:57010 (55.6 KiB) eth0 Link encap:Ethernet HWaddr 02:50:00:00:00:01 inet addr:192.168.65.3 Bcast:192.168.65.255 Mask:255.255.255.0 inet6 addr: fe80::d69:ecf4:2200:2b55/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:24340 errors:0 dropped:0 overruns:0 frame:0 TX packets:13515 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:33239694 (31.6 MiB) TX bytes:804009 (785.1 KiB) lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:65536 Metric:1 RX packets:1842 errors:0 dropped:0 overruns:0 frame:0 TX packets:1842 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1 RX bytes:167756 (163.8 KiB) TX bytes:167756 (163.8 KiB) veth7df5e61 Link encap:Ethernet HWaddr 02:F3:3F:19:7E:1E inet6 addr: fe80::f3:3fff:fe19:7e1e/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:7 errors:0 dropped:0 overruns:0 frame:0 TX packets:35 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:574 (574.0 B) TX bytes:2682 (2.6 KiB) vethee98b9b Link encap:Ethernet HWaddr 3A:A6:5E:EE:FF:DF inet6 addr: fe80::38a6:5eff:feee:ffdf/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:598 errors:0 dropped:0 overruns:0 frame:0 TX packets:616 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:56516 (55.1 KiB) TX bytes:57864 (56.5 KiB) |
Vorteil:
- Container, die im Host-Netzwerk-Stack laufen, sollten eine höhere Performance aufweisen als solche, die die docker0 Bridge und das iptables Portmapping durchlaufen.
Nachteil
- das am wenigsten geschützte Netzwerkmodell, fügt den Container dem Host-Network-Stack hinzu.
- Container, die auf dem Host-Stack eingesetzt werden, haben vollen Zugriff auf die Host-Schnittstelle.
Overlay Network
Das Overlay Network wird verwendet um Netzwerkkonfigurationen zwischen mehreren Host zu realisieren. Alle anderen Docker Network Arten können nur auf einen einzelnen Host realisiert werden.
Um ein Overlay Network realisieren zu können müssen die beiden folgenden Bedingungen erfüllt sein:
- Docker muss im swarm mode laufen
- Es muss ein Key-Value-Store wie z.B. consul vorhanden sein
Da das Overlay Network recht komplex und aufwendig ist, verzichte ich an dieser Stelle auf ein Beispiel.
Nachdem wir uns nun etwas näher mit dem Thema Docker Network beschäftig haben, schauen wir uns im nächsten Artikel das Thema Docker Microservices – Key-Value Store mit Python und Redis an
Customeressay meint
Christian Piazzi, thanks! And thanks for sharing your great posts every week!