Engine networking updates for moby 29.0 #23215
Conversation
✅ Deploy Preview for docsdocker ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
github-actions
bot
added
area/engine
robmry
changed the title
robmry
force-pushed
the
moby_networking_tweaks
branch
2 times, most recently
from
fc431e9 to
fbdde7d
Compare
Signed-off-by: Rob Murray <[email protected]>
Signed-off-by: Rob Murray <[email protected]>
With nftables on the way - refer to "firewall" instead of "iptables" in the top-level description of packet-filtering-firewalls, move out the iptables specifics, and port-publishing (which applies to both iptables and nftables). Signed-off-by: Rob Murray <[email protected]>
Adds engine/network/firewall-nftables.md Signed-off-by: Rob Murray <[email protected]>
robmry
force-pushed
the
moby_networking_tweaks
branch
from
fbdde7d to
4309ba9
Compare
|
|
||
| ```console | ||
| $ docker network create -d bridge my-net | ||
| $ docker run --network=my-net -itd --name=container3 busybox | ||
| $ docker run --network=my-net -it --name=container3 busybox |
There was a problem hiding this comment.
--name=container3 was already there but it seems unnecessary to me as it doesn't relate to anything explained above.
| In terms of networking, a bridge network is a Link Layer device | ||
| which forwards traffic between network segments. A bridge can be a hardware | ||
| device or a software device running within a host machine's kernel. |
There was a problem hiding this comment.
Do we need to keep this paragraph? Users don't need to know how network bridging works in general to use the bridge network driver. And saying 'a bridge can be a hardware device' looks confusing because the Engine doesn't support that.
| $ docker run -d --name redis example/redis --bind 127.0.0.1 | ||
| $ docker run --rm -it --network container:redis example/redis-cli -h 127.0.0.1 |
There was a problem hiding this comment.
This example can't run because it references the non-existent example/redis image. It's probably worth replacing it with the official redis image.
| $ docker run -d --name redis example/redis --bind 127.0.0.1 | |
| $ docker run --rm -it --network container:redis example/redis-cli -h 127.0.0.1 | |
| $ docker run -d --name redis redis --bind 127.0.0.1 | |
| $ docker run --rm -it --network container:redis redis-cli -h 127.0.0.1 |
| The following example runs a Redis container, with Redis binding to | ||
| `localhost`, then running the `redis-cli` command and connecting to the Redis | ||
| server over the `localhost` interface. |
There was a problem hiding this comment.
I think this could be improved. Containers have no 'localhost' interface, so this is technically wrong, and 'localhost' isn't even specified in the command. So, either replace 'localhost' with 'loopback', or maybe just use '127.0.0.1' instead?
| The following example runs a Redis container, with Redis binding to | |
| `localhost`, then running the `redis-cli` command and connecting to the Redis | |
| server over the `localhost` interface. | |
| The following example runs a Redis container, with Redis binding to | |
| 127.0.0.1, then running the `redis-cli` command and connecting to the Redis | |
| server over 127.0.0.1. |
| ### Docker and iptables chains | ||
|
|
||
| To support bridge and overlay networks, Docker creates the following custom | ||
| `iptables` chains: |
There was a problem hiding this comment.
| `iptables` chains: | |
| `iptables` chains in the `filter` table: |
| However, this is not recommended for most users as it will likely break | ||
| container networking. | ||
|
|
||
| ### Docker and iptables chains |
There was a problem hiding this comment.
Maybe worth mentioning the raw-PREROUTING chain somewhere (but this may not be the most appropriate section though)?
| > publish flag, only the Docker host and its containers can access the | ||
| > published container port. |
There was a problem hiding this comment.
Only the Docker host can access ports published on 127.0.0.1.
| > publish flag, only the Docker host and its containers can access the | |
| > published container port. | |
| > publish flag, only the Docker host. |
| In `nat` mode, when a port is published to a specific host address, that | ||
| port is only accessible via the host interface with that address. So, |
There was a problem hiding this comment.
That's not true. If a Docker host has two NICs with addresses 192.168.100.10/24 and 10.0.0.10/24, IP forwarding is enabled, and a port published on 192.168.100.10, another host in the 10.0.0.0/24 subnet can access that port if its routing table has an entry for routing 192.168.100.10 via 10.0.0.10.
| for example, publishing a port to an address on the loopback interface | ||
| means remote hosts cannot access it. |
There was a problem hiding this comment.
But this part is true as loopback addresses aren't intended to be routed.
| This changes the default binding address to `127.0.0.1` for published container | ||
| ports on the default bridge network. | ||
| Restart the daemon for this change to take effect. | ||
| Alternatively, you can use the `dockerd --ip` flag when starting the daemon. |
There was a problem hiding this comment.
As this formatted as a single line (see here), so no need to put extra new lines in the md file.
Description
firewall-nftables.mddescribing migration to experimental--firewall-backend=nftables.Reviews