distribution: private registry delete manifest results in broken state
Saw some similar issues, but didnt find anything for this particular problem.
docker registry version: registry:2 Digest: sha256:bf9b4a7b53a2f54c7b4d839103ca5be05b6a770ee0ba9c43e9ef23d602414f44
I am using a private registry backed by S3, using basic auth.
Steps:
- list tags
do:
curl https://<regsitry>/v2/manager/tags/listobserve:{"name":"manager","tags":[...,"1.3.0","1.3.1","latest"]}
I want to delete tag 1.3.1
-
get tag digest do:
curl https://<registry>/v2/manager/manifests/1.3.1 -vobserve:< Docker-Content-Digest: sha256:4cd37f5633ac95dc32ceca3359a109f2c5a20517f2ded9eace4e12dccf58835a -
delete tag do:
curl -X DELETE https://<registry>/v2/manager/manifests/sha256:4cd37f5633ac95dc32ceca3359a109f2c5a20517f2ded9eace4e12dccf58835a -vobserve:< HTTP/1.1 202 Accepted -
ensure tag is gone do:
curl https://<regsitry>/v2/manager/tags/listobserve:{"name":"manager","tags":[...,"1.3.0","1.3.1","latest"]}server logs:
INFO[0907] response completed go.version=go1.6.2 http.request.host=<registry> http.request.id=63c217c1-b5ee-4d67-9a19-8fd79f210d87 http.request.method=GET http.request.remoteaddr=<my ip>:53486 http.request.uri=/v2/manager/tags/list http.request.useragent=curl/7.43.0 http.response.contenttype=application/json; charset=utf-8 http.response.duration=52.464518ms http.response.status=200 http.response.written=200 instance.id=6484f785-0dfd-4300-afde-13e8ad9da085 version=v2.4.1
67.161.4.204 - - [31/May/2016:00:24:31 +0000] "GET /v2/manager/tags/list HTTP/1.1" 200 200 "" "curl/7.43.0"
- investigate why tag is still there
do: question life and the meaning of happiness,
curl https://<registry>/v2/manager/manifests/1.3.1 -vobserve:{"errors":[{"code":"MANIFEST_UNKNOWN","message":"manifest unknown","detail":{"Name":"manager","Revision":"sha256:4cd37f5633ac95dc32ceca3359a109f2c5a20517f2ded9eace4e12dccf58835a"}}]}server logs:
ERRO[0940] response completed with error auth.user.name=<username> err.code=manifest unknown err.detail=unknown manifest name=manager revision=sha256:4cd37f5633ac95dc32ceca3359a109f2c5a20517f2ded9eace4e12dccf58835a err.message=manifest unknown go.version=go1.6.2 http.request.host=<registry> http.request.id=2a33440c-2d08-49d0-9ee0-61a9e6cf4996 http.request.method=GET http.request.remoteaddr=<my ip>:53492 http.request.uri=/v2/manager/manifests/1.3.1 http.request.useragent=curl/7.43.0 http.response.contenttype=application/json; charset=utf-8 http.response.duration=30.85648ms http.response.status=404 http.response.written=183 instance.id=6484f785-0dfd-4300-afde-13e8ad9da085 vars.name=manager vars.reference=1.3.1 version=v2.4.1
67.161.4.204 - - [31/May/2016:00:25:04 +0000] "GET /v2/manager/manifests/1.3.1 HTTP/1.1" 404 183 "" "curl/7.43.0"
Questions: How do I actually remove this tag?
About this issue
- Original URL
- State: closed
- Created 8 years ago
- Comments: 31 (7 by maintainers)
FYI This command
does not provide the right tag digest for v2 deletion. You have to use a additional header as mentionned in the offical docs: https://docs.docker.com/registry/spec/api/#/deleting-an-image
Proceeding this way fixed the issue for me.
We’re experiencing this bug in Registry v2.6.1.
returns 4 tags, when fetching manifests of tag 8.17 as https://github.com/docker/distribution/issues/1755#issuecomment-232329426 said, it failed:
docker logs of registry as below:
How can I delete this tag now?
Hi all, thanks for reporting the issue. Unfortunately I was unable to reproduce the issue.
I made a minimal
config.ymlwhere I deployed registry with:docker run --rm -it -v $(pwd)/config.yml:/etc/docker/registry/config.yml -p 5000:5000 --name registry registry:2.6.2Configuration:
My steps:
If you are still experiencing problems, please open a new issue and provide your configuration and steps to reproduce the issue. It’s likely there are differences between my minimal setup and specific configurations that triggering the bug.
Sounds like this is fixed in 2.5.1. Closing.
If anyone is still having issues, please let me know.
@sudo-bmitch by the way,
regctlsucceeded to delete anything properly 👏 : I will look atregbotthat sounds great for automation. Thank you.I also found this cleanup.sh script that works on the local filesystem. It tends to give information on the file structure.
At the end, upgrading from 2.6 to 2.7 allowed to use the new
/bin/registry garbage-collect -moption that freed up 75% of the storage!@jcarsique There’s also the OCI media types. It’s a bit self promoting, but regclient’s regctl is what I use for this, lot of similar functionality to
reg. There, the--listflag is needed when runningimage digestto get the correct digest to delete.Double check that the digest you deleted matches what you’re seeing in those repos, e.g.
Once the manifest is removed for me, the tag is gone immediately without any GC. The GC is needed to remove some of the underlying blobs. I don’t know enough of the filesystem storage of registry to be able to advise what’s safe to remove.
@jcarsique the header for a docker manifest list is
Accept: application/vnd.docker.distribution.manifest.list.v2+json. Here’s an example cleaning v0.2.0 from this local repo:Same image, three different manifests depending on the header, and the manifest list is the real one, the registry is looking up the default platform for the v2 manifest, and automatically converting that to a v1 schema without any header. Those manifests have different digests:
Deleting the digest for a single platform leaves things in a semi-broken state:
But you can still get the manifest list digest and remove that to clean things up:
I can confirm that we are also seeing the same issue with our private registry (version 2.7.1) and using the proper headers, etc.
Note that this doesn’t happen on every image deletion. Most deletes are successful and remove the manifest/tag together but some get “stuck” in this state. One workaround solution that we have found is to push another “dummy” image to the “stuck” tag and then retry the deletion. This has worked so far, but I’m unsure if the blobs from the old tag are actually deleted on the storage or have become orphaned by this “workaround”.
@hinshun Could you please take a peak at this issue?