Will the script work by using Docker version 1.10.2?

[joda70]

The newest docker version creates a cfg file under .docker/config.json, while the script searches the user information under .docker.cfg file.

I have to do migration of a V1 registry to a v2 registry by using the new client version. This script seems to use the old client.

[mbentley]

At moment it does use an older version of the docker client. However you can specify the login credentials for your user and it will perform the login to create the credential file.

I'd like to be able make the API version or docker client somewhat user selectable but I can't commit to a date to when I would be able to add it.

[joda70]

Yes but the credential file follows the format of the new client.

[mbentley]

Are you running this via the Docker image or just running the script on your own? The expected usage is to run inside of a container. Since the docker image has the docker client version 1.6.2, it is able to support engines >=1.6.0. Is there a specific reason why you are needing to use a newer client to talk to your engine while it is performing the migration? The 1.6.2 client in the image can talk to a newer engine to be able to pull, retag, and push images. Just trying to understand your use case to see what can be done to address the issue you're running into.

[joda70]

By using the script I am obtaining an error with curl, in particular

docker run -it -v /var/run/docker.sock:/var/run/docker.sock -e DOCKER_HUB=false -e V1_NO_LOGIN=true -e V1_REGISTRY=registry1:443 -e V2_REGISTRY=registry2:443 docker/migrator

[INFO] Getting a list of images from registry1:443

[ERROR] curl => API failure
[ERROR] Migration from v1 to v2 failed!

For this reason I have started trying it locally.

The pull from V1 can be performed without auth, while the push on V2 must be performed with auth.

[mbentley]

Thanks for the additional info, that certainly helps with debugging. So as a test,try to do a curl like this:
curl https://registry1:443/v1/search?q=

This is the first curl command that it tries to execute. You should get JSON output back from the registry, for example:

# curl https://registry.core.dckrindy.io:443/v1/search?q=
{"num_results": 6, "query": "", "results": [{"description": null, "name": "library/nginx"}, {"description": null, "name": "library/hello-world"}, {"description": null, "name": "library/debian"}, {"description": null, "name": "mbentley/hello"}, {"description": null, "name": "mbentley/testssl"}, {"description": null, "name": "demo/docker-demo"}]}

If that works from your host, try to do the same command but from inside the migrator container just to make sure there isn't something screwy going on with being able to access the v1 from the container:
docker run -it --rm docker/migrator curl https://registry1:443/v1/search?q=

And just FYI, if you're just using SSL, you don't need to specify the port :443 as that is assumed but it shouldn't have an impact if you're just running the open source v1 and open source v2. I've seen some issues where if you're using certain types of auth on a v2 that specifying the port will cause auth failures.

[joda70]

No I have obtained the following error:
curl: (60) SSL certificate problem: unable to get local issuer certificate

I think I have to specify some ssl information.

[mbentley]

You might need to use the USE_INSECURE_CURL=true environment variable to get curl to ignore the cert that isn't valid. I don't think I've added the ability for curl to be able to make use of non-trusted certs from the container. Otherwise, the certs would need to be CA store inside the container.

You could do that by adding your CA cert into /etc/ssl/certs and running update-ca-certificates and then executing the migrator script. A quick Dockerfile would make this work without additional changes needing to be made (removing someone creating a PR for this from your wait time):

FROM docker/migrator:latest
COPY mycacert.pem /etc/ssl/certs/mycacert.pem
RUN update-ca-certificates

And then run your resulting image.