[BUG] --link to unexisting container yelds to pulling again image

[aijanai]

Starting a container that is linked to a non existing container should fail and just report an appropriate message.

Instead, docker tries to pull the image we are trying to launch, first, then acknowledges we already have that and then fails the launch with the aforementioned error message.
Pulling the image has nothing to do with this, it should just fail.

• I have tried with the latest version of my channel (Stable or Edge)
• I have uploaded Diagnostics
• Diagnostics ID: 199DD8FB-810A-433B-8AE3-58DB70C5F521/20190827140253

Expected behavior

Container should fail with following error message:

docker: Error response from daemon: could not get container for asd: No such container: asd.
See 'docker run --help'.

Actual behavior

Container fails, but it tries first to pull the image we already own:

Unable to find image 'nginx:alpine' locally
alpine: Pulling from library/nginx
Digest: sha256:e0f88b21626f56e5d9e038da863aee331640efb03ca7d8f453ed8243343acfaa
Status: Image is up to date for nginx:alpine
docker: Error response from daemon: could not get container for asd: No such container: asd.
See 'docker run --help'.

Information

• macOS Version: 10.14.6

Diagnostic logs

Docker for Mac: 2.1.0.1 (37199)

Steps to reproduce the behavior

Start any container (here nginx:alpine for example) with a --link to a non existing running container:

docker run --rm --link asd nginx:alpine

[guillaumerose]

This is issue is related to docker/cli. Can you reopen it in this repo (or maybe @silvin-lubecki or @thaJeztah can transfert it).

[thaJeztah]

Thanks for reporting; I understand the problem (in this case the image was already present, but not tagged, but in other situations running such a container could result in first having to wait for the image to be pulled, only to find out the configuration is incorrect).

Unfortunately, this is currently a bit of a hard problem to fix.

When you docker run (or docker create) a container, the Docker CLI first attempts to call the daemon API to create the container; if that call fails because the image is missing, the CLI asks the daemon to pull the image, then try again to create the container. (you can find the code for that here: https://github.com/docker/cli/blob/v19.03.1/cli/command/container/create.go#L215-L234)

The reason the image has to be pulled before the container is created, is that some of the validation steps depend on the image's platform; in most situations, the platform would be the same as the platform that the daemon runs on, but (for example) when running LCOW (Linux Containers On Windows), the daemon would be running a Linux container on a Windows daemon, and has to validate the container's config using the rules that apply to Linux containers (see https://github.com/moby/moby/blob/ab47e16cc530ce1dd722827e70c6b50593048c85/daemon/create.go#L115-L138)

There are plans to remove the LCOW functionality from the daemon (and move to the new LCOW implementation that's worked on in containerd) (see moby/moby#39533), but we're not there yet, and possibly there's other situations where the image config would still be needed before further validation can be performed.

Is there a specific reason you're using the --link option? Note that the --link on the default "bridge" network is a legacy feature; it's still there for backward compatibility, but it has various limitations (among which a security impact, because using the legacy links will share environment variables between containers, which may include credentials/secrets; https://docs.docker.com/v18.09/network/links/)

Instead of using links, you can use a custom network; doing so will allow you to connect to other containers attached to the same network, using their name as hostname;

For example:

# create a custom network
docker network create mynetwork

# start a container, attached to the network. the container must have a name
# be registered in the embedded DNS server
docker run -d --name one --network=mynetwork nginx:alpine

# start a second container on the same network; just to illustrate; this container is
# "pinging" the first container
docker run -d --name pinger --network=mynetwork nginx:alpine sh -c 'while true; do ping -c1 one; sleep 2; done'

# check the logs of the pinger container to see it's able to resolve the `one` container
docker logs pinger
PING one (172.18.0.3): 56 data bytes
64 bytes from 172.18.0.3: seq=0 ttl=64 time=0.190 ms

--- one ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 0.190/0.190/0.190 ms
PING one (172.18.0.3): 56 data bytes
64 bytes from 172.18.0.3: seq=0 ttl=64 time=0.123 ms

Using custom networks also has the advantage that you can update/replace the "linked" (one) container without having to re-create the pinger container;

# remove the `one` container
docker rm -f one 

# the `pinger` container will now fail
docker logs pinger
...
--- one ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 0.079/0.079/0.079 ms
ping: bad address 'one'

# however, creating a (new) `one` container
docker run -d --name one --network=mynetwork nginx:alpine

# ..  will make the `pinger` container reconnect again
docker logs pinger
...
ping: bad address 'one'
ping: bad address 'one'
PING one (172.18.0.3): 56 data bytes
64 bytes from 172.18.0.3: seq=0 ttl=64 time=0.167 ms

--- one ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 0.167/0.167/0.167 ms

[thaJeztah]

🤦‍♂ Just looking at another report related to this (moby/moby#39823), I see I misinterpreted the initial pulling (thought this part was "expected" because the image wasn't there on the first run). I see there's indeed a regression in Docker 19.03 (ironically, actually caused by improved error handling).

I know what's causing it, and should have a fix soon.

[thaJeztah]

pull request; moby/moby#39852

[docker-robott]

Closed issues are locked after 30 days of inactivity.
This helps our team focus on active issues.

If you have found a problem that seems similar to this, please open a new issue.

Send feedback to Docker Community Slack channels #docker-for-mac or #docker-for-windows.
/lifecycle locked