search

docker-library / busybox

Docker Official Image packaging for Busybox
http://busybox.net
396 stars 127 forks source link

nc: bad address "docker container" #54

Closed dran-dev closed 5 years ago

dran-dev commented 5 years ago

When using netcat to wait for a docker container to be up, using container name using the latest busybox image, I am getting an error nc: bad address "docker container"

wglambert commented 5 years ago

Trying to resolve the container's hostname won't work from the host, their hostnames are only resolvable on an inter-container network. Also netcat requires a tcp/udp port, which you would have to open on the image if it's not already. ping might be more what you're looking for, or giving a docker exec command as it will wait until the container processes it.

You could also take a look at the healthcheck repo and make/find one for busybox

Since this isn't an error with the image you should ask the Docker Community Forums, the Docker Community Slack, or Stack Overflow. As these repositories are for issues with the image and not necessarily for questions of usability

dran-dev commented 5 years ago

@wglambert This is the command I used to check. This uses netcat from with in the inter-container network. BUSYBOX_IMG used is busybox:latest docker run --name "my-container" --network "my-network" $BUSYBOX_IMG sh -c "nc -z my-other-container 9042"

The same command was working 3 days back. I believe there was an update recently.

wglambert commented 5 years ago

I'm not able to reproduce your issue, you're not using the default bridge network are you? As that one doesn't do hostname resolution for containers

$ docker run --rm -dit --network=web -e MYSQL_ROOT_PASSWORD=root --name mysql mysql

$ docker run --rm --network=web busybox nc -zv mysql 3306
mysql (192.168.32.2:3306) open
yosifkit commented 5 years ago

The same command was working 3 days back. I believe there was an update recently

What was updated recently? busybox image, docker daemon, other service image, host kernel?

The busybox image on the Docker Hub has not been updated since https://github.com/docker-library/official-images/pull/4929 (which was only a change away from rawgit). The previous change was a version bump: https://github.com/docker-library/official-images/pull/4904, which corresponds to #53 and https://github.com/docker-library/busybox/commit/515340ec869bceb847b952e0a7ceabf47d3d38ea.

dran-dev commented 5 years ago

@yosifkit I was referring to https://hub.docker.com/r/library/busybox/tags/

yosifkit commented 5 years ago

The "updated" tags (1.29-musl and 1.29.3-musl) are not latest and so would not have any effect if you are using busybox:latest. Besides, the digest for the 1.29-musl manifest list has not changed in a month:

Fresh pull:

$ docker pull busybox:1.29-musl
1.29-musl: Pulling from library/busybox
eba486cded61: Pull complete 
Digest: sha256:900af4a5c0bde80af6a87695ad209f0506dcb148179a3a217899fc4deb123f71
Status: Downloaded newer image for busybox:1.29-musl

Compared to the hash grabbed last month (https://github.com/docker-library/repo-info/blame/master/repos/busybox/remote/1.29.3-musl.md#L4):

$ docker pull busybox@sha256:900af4a5c0bde80af6a87695ad209f0506dcb148179a3a217899fc4deb123f71

~So it seems to me that the Docker Hub scan date changed the "last updated" date for that image. I'll see if someone at docker can look as to why that happened (but it is unrelated to this issue).~ it was probably the server that pushes manifest lists getting an bad response and pushing an manifest identical to the already pushed manifest (which is why it has the same sha).