As an implementation detail, Docker allocates part of that IP address range for each Docker network that gets created. Within that address range, typically the .1 address is the host and then addresses are allocated sequentially for each container that's attached to the network.
In the answer you link to, for example, it's very possible that Docker will assign 172.22.0.0/16 to the network listed in the docker-compose.yml
file. Then 172.22.0.1 would be the host, 172.22.0.2 would be the first container in the docker-compose.yml
, and 172.22.0.3 would be the second (db
). When there's an error, say, connecting to db:27017
, the resolved address might print out in the error message.
If a Docker-internal IP address is hard-coded in your application somewhere that's probably a mistake. There's no guarantee that the same address or even the same network will be in use if you restart your container somewhere else. These addresses are also unreachable from other hosts; from outside the VM, if Docker is running in a VM; and even from non-container processes on the same host, except on native Linux systems.
Networking in Compose in the Docker documentation is a good practical reference. Note that it doesn't describe this IP allocation at all, since it's mostly an implementation detail. The examples in Networking with standalone containers show low-level diagnostic commands to dump out Docker network details; while these aren't usually useful, they do show Docker allocating /16 networks in that 172.{16...31} reserved range.