docker is using the v1 registry api when it should

问题:

I'm trying to use a self hosted docker registry v2. I should be able to push a docker image, which does work locally on the host server (coreos) running the registry v2 container. However, on a separate machine (also coreos, same version) when I try to push to the registry, it's try to push to v1, giving this error:

Error response from daemon: v1 ping attempt failed with error: Get 
https://172.22.22.11:5000/v1/_ping: dial tcp 172.22.22.11:5000: i/o timeout. 
If this private registry supports only HTTP or HTTPS with an unknown CA 
certificate, please add `--insecure-registry 172.22.22.11:5000` to the 
daemon's arguments. In the case of HTTPS, if you have access to the registry's 
CA certificate, no need for the flag; simply place the CA certificate at 
/etc/docker/certs.d/172.22.22.11:5000/ca.crt 

both machine's docker executable is v1.6.2. Why is it that one works and is pushing to v2 but the other is v1?

Here's the repo for the registry: https://github.com/docker/distribution

回答1:

You need to secure the registry before you can access it remotely, or explicitly allow all your Docker daemons to access insecure registries.

To secure the registry the easiest choice is to buy an SSL certificate for your server, but you can also self-sign the certificate and distribute to clients.

To allow insecure access add the argument --insecure-registry myregistrydomain.com:5000 to all the daemons who need to access the registry. (Obviously replace the domain name and port with yours).

The full instructions (including an example of your error message) are available at: https://github.com/docker/distribution/blob/master/docs/deploying.md

Regarding the error message, I guess Docker tries to use v2 first, fails because of the security issue then tries v1 and fails again.

回答2:

This may be due to an env variable being set. I had a very similar issue when using a system with this env variable set.

export DOCKER_HOST="tcp://hostname:5000"

Running docker login http://hostname:5000 did not work and gave the same v1 behaviour. I did not expect the env variable to take precedence over an argument passed directly to the command.