I am trying to list the layers digest of an image (e.g.: ubuntu) that is loaded to a docker registry. I am basically looking for the equivalent of docker manifest inspect --verbose <image-name>
for docker registry and which gives a similar output:
From the server that is hosting the registry, I am running the following command successfully to list the images inside the registry:
curl -k -X GET -u admin:root https://docker.registry.url/v2/_catalog | python -mjson.tool
I can also run the following command to see the tag of my image:
curl -k -X GET -u admin:root https://docker.registry.url/v2/ubuntu/tags/list | python -mjson.tool
But when I try to use the following command (as in here) to list the digests:
curl -k -v -s -X GET -u admin:root https://docker.registry.url/v2/ubuntu/manifests/latest -H 'Accept: application/vnd.docker.distribution.manifest.v2+json' | python -mjson.tool
… I get the following two messages:
- "HTTP/1.1 404 Not Found"
- "errors: "code": "MANIFEST_UNKNOWN"
as per the following output:
* About to connect() to docker.registry.url port 443 (#0)
* Trying <server-ip-address>...
* Connected to docker.registry.urll (<server-ip-address>) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
* skipping SSL peer certificate verification
* SSL connection using TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
* Server certificate:
* subject: CN=docker.registry.url
* start date: Oct 22 13:15:18 2021 GMT
* expire date: Oct 21 13:00:19 2031 GMT
* common name: docker.registry.url
* issuer: CN=docker.registry.url
* Server auth using Basic with user 'admin'
> GET /v2/ubuntu/manifests/latest HTTP/1.1
> Authorization: Basic YWRtaW46QWlyc3BhbjEyMw==
> User-Agent: curl/7.29.0
> Host: docker.registry.url
> Accept: application/vnd.docker.distribution.manifest.v2+json
>
< HTTP/1.1 404 Not Found
< Server: nginx/1.21.3
< Date: Tue, 08 Mar 2022 15:00:36 GMT
< Content-Type: application/json; charset=utf-8
< Content-Length: 187
< Connection: keep-alive
< Docker-Distribution-Api-Version: registry/2.0
< X-Content-Type-Options: nosniff
<
{ [data not shown]
* Connection #0 to host docker.registry.url left intact
{
"errors": [
{
"code": "MANIFEST_UNKNOWN",
"detail": {
"Name": "ubuntu",
"Revision": "sha256:9c152418e380c6e6dd7e19567bb6762b67e22b1d0612e4f5074bda6e6040c64a"
},
"message": "manifest unknown"
}
]
}
1- Why am I getting the above error?
2- How do I get the list of manifests of an image from a docker registry?
2
Answers
Workaround:
Not sure if this answer is 100% related to the actual question, but I needed to delete images in my registry; using registry:2.8.1, followed this but even garbage collector didn’t clear images for me so as a workaround I’m clearing images by not having them mounted as a volume – and just restarting the whole registry; and if I need to clear a different group of images independently, I can set up a second registry on a different port and also not use a mounted volume.
But in case it works for someone else here’s some other commands:
1 Get Digest
there should be this section:
2 run garbage collector
3 delete
Given the error message, the registry understands the tag, and is trying to pull a specific digest but cannot find it. One of the most common causes of this is running a GC on the registry with a multi-platform image because of a longstanding bug with the GC design.
In the command:
You are requesting a single platform manifest, so the registry will automatically dereference a multi-platform image manifest. Checking that digest from Hub, that shows up as the following:
You can better see what’s happening by pulling the manifest list by allowing an additional media type:
An example of that looks like:
Since your registry is in a corrupt state, you’re likely best off deleting the images and starting over, without the GC process. But you can copy individual images back to the server by digest:
I even have the flag
--force-recursive
for this because I’ve seen it happen too often:The above is shown with my own regclient/regctl tool, but there’s also crane, scopeo, and I’m sure several other tools including whichever you used to first copy the image yourself. I’d avoid using curl to pull the images yourself for more than a demo since you’ll eventually run into scenarios other media types or token authentication that make the scripting around the curl command very complicated (I started down that path before deciding it was easier to write regclient).