Docker registry 2.0 API v2

I pulled and setup the local docker registry:2.0

I have tried pushing an image successfully, but when ever I try searching for an image I get 404:

  • Does AWS support Kubernetes?
  • Shortcut for deleting docker image and all containers using it?
  • Docker-compose corrupted directory when shared a multiple file/directory in the same mounting point
  • docker jenkins dsl pipeline
  • $GEM_HOME and $GEM_PATH are wrongly set in Passenger
  • Connect spark master to spark slave through docker compose
  • root@ip-10-232-0-153:~# curl -v -X GET http://localhost:5000/v2/search
    * Hostname was NOT found in DNS cache
    *   Trying 127.0.0.1...
    * Connected to localhost (127.0.0.1) port 5000 (#0)
    > GET /v2/search HTTP/1.1
    > User-Agent: curl/7.35.0
    > Host: localhost:5000
    > Accept: */*
    >
    < HTTP/1.1 404 Not Found
    < Content-Type: text/plain; charset=utf-8
    < Docker-Distribution-Api-Version: registry/2.0
    < Date: Fri, 08 May 2015 00:00:45 GMT
    < Content-Length: 19
    <
    404 page not found
    * Connection #0 to host localhost left intact
    

    Also when I try to curl localhost:5000, I just get a 404:

    404 page not found
    

  • Pass parameters to docker container using docker run command
  • Java process in Docker container doesn't exit on end of main()
  • Should I run the init process inside a Docker container or not? [closed]
  • Self-hosted alternative to hub.docker.com?
  • autoredeploy new image to a docker swarm
  • Using customized AMI in Elastic Beanstalk (Multi-container Docker) via awsebcli
  • 8 Solutions collect form web for “Docker registry 2.0 API v2”

    UPDATE (14 April 2016): Still not here in the distribution roadmap, but here is a particular issue about search.

    UPDATE (12 November 2015): The API endpoints still do not yet exist and are not yet in the Docker Registry roadmap.

    The problem here is that the new v2 Docker registry doesn’t support that particular endpoint yet, as of this question and answer. You can check the source itself for the route endpoints, and you’ll see that most of the API endpoints involve simple operations like uploading and tagging, but no implementation yet of the search endpoint. It’s important here to note that the v2 registry is a completely different project than the v1 registry. It’s even written in a completely different language (v1 was a Python project, whereas v2 uses Go, which is more in line with the rest of the Docker projects). It took me some time and serious reading to understand the dichotomy here between the registries. It is worth looking at this particular Github issue about the v2 registry for a deep-dive into a recent discussion on the state of the v2 registry, as well as some discussion about where they’ve been taking it.

    So there’s no search endpoint in the v2 registry yet. You can list your image by tag or by the image name itself as mentioned in task number 8 in this documentation.

    if you’re on windows, here’s a Powershell script to query the v2/_catalog from windows with basic http auth.

    https://gist.github.com/so0k/b59382ea7fd959cf7040

    FYI, to use this you have to docker pull distribution/registry:master instead of docker pull registry:2. the registry:2 image version is currently 2.0.1 which does not come with the catalog endpoint.

    On Linux (Centos 7), I use this as long as the registry image is the only container running: This will list all images pushed to the resistry/container.
    I put it in a script and tweaked the cut params to get what I wanted as the length of image names does vary a bit. run as sudo “script-name.sh”

    grep -r -o "vars\.name=.* vars.reference=.*" /var/lib/docker/containers/* | cut -c 167-220 | sed 's/ver.*$//' | sed 's/vars\.name=//' | sed 's/ vars\.reference=/:/' | sort -u
    

    Today i tried the registry:master image, but doesn’t exists.

    xotl@xotl-VM:~$ docker run registry:master
    Unable to find image 'registry:master' locally
    Pulling repository docker.io/library/registry
    Tag master not found in repository docker.io/library/registry
    xotl@xotl-VM:~$ 
    

    Now you can run the registry:2 and will have the endpoint.

    If i visit http://localhost:5000/v2/_catalog in my machine i can see this output {"repositories":["ubuntu"]}, wich is correct. Also tried http://localhost:5000/v2/ubuntu/tags/list and got this response {"name":"ubuntu","tags":["latest"]}, so it works.

    You can take a look at the docs.

    @Xotl
    curl -X GET registry.com:5000/v2/lashou/centos/tags/list
    {"errors":[{"code":"NAME_UNKNOWN","message":"repository name not known to registry","detail":{"name":"lashou/centos"}}]}
    

    Docker registry search functionality v2 is not supported at the time of this writing.
    See discussion since Feb 2015: https://github.com/docker/distribution/issues/206

    Registry V2 is like dropping images into a black bag, hope you remember what you dropped in and what you named the image. Don’t even think about deleting an image. I do not want to rip and replace V2 with V1; even though V1 works and has several tools that work with V1 including search and delete. I started with registry V2 from the marketing; better security and performance.

    Ubuntu 14.04.3 LTS, CoreOS 723.3.0
    registry github.com/docker/distribution v2.1.1

    I wrote a script, named view-private-registry to search registry V2 REGISTRY_STORAGE_FILESYSTEM_ROOTDIRECTORY. It works on any of my systems that has the REGISTRY_STORAGE_FILESYSTEM_ROOTDIRECTORY mounted. Let me know of any changes you would make, thanks.

    Script:
    https://github.com/BradleyA/Search-docker-registry-v2-script.1.0

    #!/bin/bash
    # %W% %G% %U%
    #
    #       View private registry,
    #               if REGISTRY_STORAGE_FILESYSTEM_ROOTDIRECTORY is mounted on your system
    #
    REGISTRY_STORAGE_FILESYSTEM_ROOTDIRECTORY="/mnt/three/docker-registry/registry-data"
    #
    find $REGISTRY_STORAGE_FILESYSTEM_ROOTDIRECTORY -print | \
        grep 'v2/repositories' | \
        grep 'current' | \
        grep -v 'link' | \
        sed -e 's/\/_manifests\/tags\//:/' | \
        sed -e 's/\/current//' | \
        sed -e 's/^.*repositories\//    /' | \
        sort > /tmp/a1
    cat /tmp/a1
    wc -l /tmp/a1 > /tmp/a2
    echo "Number of images: `cat /tmp/a2 | awk {'print $1'}`"
    echo "Disk space used:  `du -hs $REGISTRY_STORAGE_FILESYSTEM_ROOTDIRECTORY`"
    rm /tmp/a1 /tmp/a2`
    

    Output:

    `$ ./view-private-registry`
    busybox:latest
    gcr.io/google_containers/etcd:2.0.9
    gcr.io/google_containers/hyperkube:v0.21.2
    gcr.io/google_containers/pause:0.8.0
    google/cadvisor:latest
    jenkins:latest
    logstash:latest
    mongo:latest
    nginx:latest
    python:2.7
    redis:latest
    registry:2.1.1
    stackengine/controller:latest
    tomcat:7
    tomcat:latest
    ubuntu:14.04.2
    Number of images:   16
    Disk space used:    1.7G    /mnt/three/docker-registry/registry-data
    

    The latest version of Docker Registry available from https://github.com/docker/distribution supports Catalog API. (v2/_catalog). This allows for search capability.

    If interested, you can try docker image registry CLI I built to make it easy for using the search features in the new Docker Registry v2 distribution 🙁https://github.com/vivekjuneja/docker_registry_cli)

    Correct.

    It is simply an example of an implementation that works to obtain some list of images. Yes it is assumed this is a generic registry2.0 startup. for example
    $ sudo docker run –name=myregistry -d -p port:port myregistry:1.0.

    Basically the point is each container has a log file …some-path/containers… ID-json.log. In that file information is stored about images pushed to the running registry. So it can be used to extrapolate an image list. As raw as it is it is better than nothing. Not a solution to the bigger search/catalog issue but a way to get an image list. It is a very customized workaround to solve a problem while waiting for the “official” fix.

    Docker will be the best open platform for developers and sysadmins to build, ship, and run distributed applications.