Not able to "bundle" my container into an easy build

Technical Support
, , , ,
42

Hi Steve,

Thank you for the quick reply — looking forward to what curl -v http://[::1]:5000/v2/ returns; that one command settles the diagnosis.

Two clarifications on the puzzles you raised:

“Fresh Feb/Mar install should behave like Jeremias’s Jul install” — not necessarily. Between those dates there’s ~3 months of Windows Update, wsl --update (Store WSL pulls new networking behavior fairly often, and there were several nat/mirrored issues in the last 12 months), apt upgrade, and Docker Engine minor bumps — you’re on 29.6.1, Jeremias on 29.3.1. Any of those layers can shift IPv6/loopback handling. The only real apples-to-apples check is wsl --version and docker version on both machines.

“Why does Jeremias’s log show https://?” — there are two independent HTTPS conversations in that log, easy to conflate:

  • https://127.0.0.1:22376 "POST /v1.44/images/create…" — that’s the TCB Python client talking to the DinD daemon’s Engine API. DinD auto-generates a cert (see DOCKER_TLS_CERTDIR=… earlier in the log) so its API port is TLS by design. Unrelated to the registry.
  • The DinD> lines mentioning https://localhost:5000/v2/ are the registry attempt from DinD’s Docker daemon. Docker’s registry client always probes HTTPS first, even for registries in the insecure-registry list; --insecure-registry only enables the HTTP fallback after the probe. Both your log and Jeremias’s log show that first HTTPS probe. The difference is that on his box the HTTP fallback succeeds silently, while on yours the probe dies with ECONNREFUSED on [::1]:5000 — and the HTTP retry hits the same [::1] and fails identically, which is why you also saw an http://localhost:5000/… line with the same error.

So HTTPS in the log ≠ “the registry was actually reached over HTTPS.”

Best,
Daniel

That ps output lines it up. The registry container is publishing v4-only (127.0.0.1:5000 plus the container-internal 172.17.0.2:5000), so [::1]:5000 genuinely has no listener, which is exactly why the DinD daemon’s IPv6 attempt gets ECONNREFUSED.

That gives you a fourth, cleanest option in addition to A/B/C: fix the publish so the registry listens on both families. Recreate the registry without the 127.0.0.1: prefix (and remove any -p [::1]:… too):

docker rm -f registry
docker run -d -p 5000:5000 --restart always --name registry registry:2
docker push localhost:5000/hello-world:latest    # re-push, the old one was on the deleted registry

docker ps should now show 0.0.0.0:5000->5000/tcp, [::]:5000->5000/tcp. Then re-run bundle — DinD’s ::1 attempt should now succeed and no IPv6 disabling is needed.