Connect a Container to a Service Running on the Docker Host
This challenge focuses on Docker Engine running directly on a Linux machine. Docker Desktop runs Docker Engine inside a separate VM and provides some of the host connectivity out of the box, so the commands from this challenge may behave differently on your computer.
Your company is moving its services into containers, and your team works on the shop service.
Historically, the development version of the shop service and all its dependencies have run on a single VM and talked to each other over localhost.
You have a developer workstation for experiments called dev-01.
The team has packaged the shop into the shop:v1 image and started it there with the following command:
docker run -d --name shop \
-p 80:8080 \
-e INVENTORY_URL=http://localhost:8000 \
shop:v1
The container is running, but its web UI shows an error instead of the product list. Apparently, the containerized application cannot reach the inventory API, which still runs right on the host as a background service.
Your task: recreate the shop container so that it loads the products from the inventory API running on the host.
Note that the whole team is going to use your docker run command on their own workstations, and these VMs differ.
Each of them has its own IP address, and Docker Engine on some of them uses a different subnet for the default bridge network.
You need to come up with a command that will work on all of them without changes.
For the sake of reproducibility, keep the shop:v1 image as it is, and keep the container's name and its published port 80.
Hint 1
Inside a container, localhost refers to the container's own network namespace,
so the shop looks for the API in the wrong place.
The quickest fix is to restart the shop container using the docker run command with the --network host flag.
With it, the container shares the network namespace of the dev-01 workstation, including its localhost.
However, this is also the least secure and least future-proof option. The container loses its network isolation, and its ports can collide with the ports of the host and other containers. Use it only when you are in a rush. This challenge requires you to look for a more elegant solution.
Hint 2
For historical reasons, the inventory API listens on 0.0.0.0, which means all addresses of the workstation machine:
ss -lntp
ip -br addr
Try reaching the inventory API from inside the shop container through the address of one of the host's interfaces using
the docker exec shop wget ... command.
If wget can do it from inside the shop container, the shop application will be able, too.
Now you need to find a way to pass the API address to the container.
Hint 3
The INVENTORY_URL variable can point to the address of the workstation's main network interface (eth0).
This works on dev-01, but every workstation has its own address,
so the same command would not work for your teammates.
In an office network, it could even make their shops use the inventory API of your workstation.
Hint 4
Another candidate is the address of the docker0 bridge.
which Docker Engine creates by default.
However, the subnet of the default bridge is a setting of Docker Engine, and it can differ between hosts.
On the workstations of your team, it does, so you cannot just hardcode 172.17.0.1.
Hint 5
Since there is no single IP address you can assume unchanged across Docker hosts, Docker provides a "native" workaround.
The --add-host <name>:<ip> flag of docker run adds an entry to the container's /etc/hosts file,
which resolves to the given address.
Docker also defines a special host-gateway value,
which you can use instead of a fixed IP address.
When a container is created, Docker Engine replaces the special host-gateway value with the IP address of one of the host's interfaces
(usually, the one of the default docker0 bridge, but it can be overridden in /etc/docker/daemon.json).
The <name> part of the --add-host entry can be anything.
The conventional choice is host.docker.internal, but it has no special meaning in Docker Engine,
so you can pick a shorter or more relevant name.
Note that in Docker Desktop, host.docker.internal is a special DNS name which always resolves to some internal address for reaching the host.
However, this challenge focuses specifically on Docker Engine, because this is what productions use.