Description
File: network/none.md
$ docker exec no-net-alpine ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: tunl0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN qlen 1
link/ipip 0.0.0.0 brd 0.0.0.0
3: ip6tnl0@NONE: <NOARP> mtu 1452 qdisc noop state DOWN qlen 1
link/tunnel6 00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00 brd 00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00
The example output is misleading, as it shows (ipip-related) network interfaces tunl0 and ip6tnl0 which are not present when I am executing this example on different systems with Docker CE 19.04, such as on Ubuntu 19.10 Server. In particular, this example shows network interfaces that are highly specific to any container isolation intended to be achieved with --network none and contradict the the first paragraph.
Please remove the misleading output, so it looks like the following one, matching what a typical user on a typical "standard" Docker/host setup will experience when executing the example for herself/himself:
$ docker exec no-net-alpine ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
Additionally, the first paragraph is contradictory in itself; if the networking stack is completely disabled, how can a loopback network device then be created, if the container has no networking stack. Technically, it isn't possible to create a Docker container (at least on Linux) or in fact any Linux process without any network stack attached to it, be it its own, or a shared one. The fundamental rule of Linux is: every process has exactly one network stack (but not every process has its own).
If you want to completely disable the networking stack on a container [emphasis mine], you can use the
--network noneflag when starting the container. Within the container, only the loopback device is created.
The option net=none doesn't disable the network stack of this container at all. In fact, the container has its own network stack, which can be seen, for instance, by checking ls -l /proc/self/ns/net inside a container started with net=none and from the container host: it will clearly show two different namespace identifiers (inode numbers). Also, sudo lsns -t net confirms this.
A possible fix for the contradiction could read like:
If you want to disable Docker-managed networking interfaces, such as eth0, you can use the
--network noneflag when starting the container. Within the container, only the loopback device is created.