-
Notifications
You must be signed in to change notification settings - Fork 2.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Garbage collect untagged manifests #1844
Comments
#1813 is a pre-requisite to this feature |
I assume that the first use case should already be working:
But there's no way to implement the second one. |
In our company we use tags that match the branch name og the code, which corresponds to your use case 2. I was actually quite surprised that this wasn't the standard behaviour, since as far as I can see there is no way to retrieve the old manifest digests from the API. Our current workaround is to delete the current manifest before pushing a new one. |
Use case 2 is extremely common. Blobs that would be eligible for garbage collection were it not for untagged manifests consume the majority of storage space allocated to the private registries I'm responsible for. Is anyone working on this? |
Correct me if I'm wrong but second use case scenario is: For each repository:
After above steps garbage collector will reclaim disk space. |
Yeah that would be how to solve it. Though there are 3 more steps:
|
This should solve point 1: #2199 |
Fixed by #2302 ? |
Is it released yet? |
Does it require putting registry to read only mode or restarting registry? |
It was merged into master ~two weeks ago. Latest release was in July 2017. I tried a build of the registry (through https://github.com/docker/distribution-library-image) and it seems to work (pushed several images on the same tag, all but the latest push, but I didn't try it on a large setup. It still requires a docker command ( It works without changing the registry mode, but I am not experienced enough with Docker to say if that's safe - feedback welcome. I may be wrong, but I'd test to run it as a daily cron task rather than having a remote script triggering it. |
I'd love to see a new release tagged so this functionality can start to permeate the ecosystem :) |
If we remove all the tag of the existing image, we won't be able to actuallly delete it from the registry. As a result, the registry size will grow up indefinitely. Any tag can potentially be already used by an image and by the last "string" attached to it. So before we apply a tag, we delete any potential existing tag. See: distribution/distribution#1844 Change-Id: I43ab70660a68d230487124a270dfd635bda16469
Wouldn’t this be problematic for people that are just pushing digests? |
Maybe if they only pushed digests they should not call the garbage-collect command. However I really do not see a reason to only push digests. |
@taladar Why push tags, if your entire pipeline just needs digests? |
@sargun It's just a feature. You're not required to use it. If you can afford infinite disk space you would just not use the "garbage collect untagged manifests" option. But people running small projects actually run out of space sometimes :) Yes, there's a drawback, as if you're running tag "latest" and you push another tag "latest" (thus automatically deleting a previous digest if it isn't tagged) your services will fail as digest that they're running wouldn't be found. As a workaround you could just tag every image you push with a timestamp. This way you would essentially have human readable digests and ability to remove, say, all digests older than a week. To implement the same functionality now you have to go through unbearable pain implementing that service which would talk to registry through its API which still doesn't support proper deletion and then restart it to garbage collect. |
If we remove all the tag of the existing image, we won't be able to actuallly delete it from the registry. As a result, the registry size will grow up indefinitely. Any tag can potentially be already used by an image and by the last "string" attached to it. So before we apply a tag, we delete any potential existing tag. See: distribution/distribution#1844 Change-Id: I43ab70660a68d230487124a270dfd635bda16469
2.7.0 has been officially released |
As suggested in #1600, there should be a garbage collect option to delete all manifests that are not references by any tags (dangling).
Use case 1:
Use case 2:
The text was updated successfully, but these errors were encountered: