[Container-tools] Help needed on searching Docker images on third-party registries

Tue Aug 18 09:32:49 UTC 2015

Hello,

I'm currently working on Docker tooling for Eclipse and one of the new features that we want to implement is Images Search on registries.
From my current understanding, there is no standard for searching images on third-party registries because the search operation isperformed by an Index service that works aside of the core registry, while the latter really cares about pulling/pushing images (with credentials if needed). 

For example, Docker Hub runs on Registry 0.6.3 and from the CLI a user can do something like "docker search wildfly".

But if you run a registry in a Docker container, this might not work, depending on the version of the Registry image that you use: https://github.com/docker/docker-registry <https://github.com/docker/docker-registry> or https://github.com/docker/distribution <https://github.com/docker/distribution>. 

With https://github.com/docker/docker-registry <https://github.com/docker/docker-registry> it is possible to call the /v1/repositories endpoint such as this:

$> curl -v https://index.docker.io/v1/repositories/jboss/wildfly/tags <https://index.docker.io/v1/repositories/jboss/wildfly/tags>
[{"layer": "8c032ac6", "name": "latest"}, {"layer": "53049889", "name": "8.1.0.Final"}, {"layer": "3e5bdf36", "name": "8.2.0.Final"}, {"layer": "04b676ff", "name": "8.2.1.Final"}, {"layer": "9258f793", "name": "9.0.0.Final"}, {"layer": "827b71de", "name": "9.0.1.Final"}]
 (since Docker Hub runs Registry 0.6.3 as curl -v https://index.docker.io/v1/_ping <https://index.docker.io/v1/_ping> reveals)

Now, running the same command on Registry 0.9 gives a slightly different response format:
$>curl -v http://192.168.59.103:5000/v1/repositories/centos/tags <http://192.168.59.103:5000/v1/repositories/centos/tags>
{"latest": "8efe422e6104930bd0975c199faa15da985b6694513d2e873aa2da9ee402174c"}

This is slightly annoying but I guess I handle the different format message in a way or another.

Now, using Registry 2.1 (with port mapping 5000->6000 to avoid conflicts):
$>curl -v http://192.168.59.103:6000/v2/repositories/centos/ <http://192.168.59.103:6000/v2/repositories/centos/>
404 page not found

Even more, I found this comment on https://github.com/docker/distribution/blob/master/ROADMAP.md#indexing-search-and-discovery <https://github.com/docker/distribution/blob/master/ROADMAP.md#indexing-search-and-discovery> 
"We expect that someone attempts to address the problem with the existing tools and propose it as a standard search API or uses it to inform a standardization process."
In the mean time, it is possible to list _all_ images using another endpoint, but this is not _searching_.

If I try to perform a search on Red Hat Docker registry located at docker-registry.usersys.redhat.com <http://docker-registry.usersys.redhat.com/> :
$>curl -v http://docker-registry.usersys.redhat.com/v1/repositories <http://docker-registry.usersys.redhat.com/v1/repositories>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<title>404 Not Found</title>
<h1>Not Found</h1>
<p>The requested URL was not found on the server.  If you entered the URL manually please check your spelling and try again.</p>

AFAICS, the search box on docker-registry.usersys.redhat.com <http://docker-registry.usersys.redhat.com/> triggers a JS function that filters DIVs with matching images, so this is a pure client-side implementation.

To summarize: from my current understanding there does not seem to be a standard API for searching images on registries.
If we want to provide support for Image Search on third party registries (I'm thinking about Red Hat registry and OpenShift v3) via plugins on top of the Docker tooling, we would need at least some endpoints to call. 

Do you have any info about that ? Is there a plan to implement a search endpoint for docker-registry.usersys.redhat.com <http://docker-registry.usersys.redhat.com/> or for other registries that customers may use to pull official Docker images ?

Best regards,
/Xavier

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/container-tools/attachments/20150818/e8374e5b/attachment.htm>