docker-registry-browser
docker-registry-browser copied to clipboard
klausmeyer
Hide images with no remaining tags after deletion
Hi, there is no delete button in the current app version. Did I missing some setup or something else?
Config: version: 0.1 log: fields: service: registry storage: cache: blobdescriptor: inmemory filesystem: rootdirectory: /var/lib/registry http: addr: :5000 headers: X-Content-Type-Options: [nosniff] health: storagedriver: enabled: true interval: 10s threshold: 3 delete: enabled: true
Run commands:
docker run -tdi -p 5000:5000
-v /root/registry/config.yml:/etc/docker/registry/config.yml
-v /root/registry/_data:/var/lib/registry
-v /root/registry/certs:/certs
-e REGISTRY_STORAGE_DELETE_ENABLED=true
-e REGISTRY_HTTP_TLS_CERTIFICATE=/certs/domain.crt
-e REGISTRY_HTTP_TLS_KEY=/certs/domain.key
--network=bridge
--restart=unless-stopped
--name=registry-srv
--hostname=registry-srv
-l hidden="true"
registry:2
docker run -tdi -p 80:8080
-e DOCKER_REGISTRY_URL=https://xyz.somewhere.com
--restart=unless-stopped
--name=registry-browser
--hostname=registry-browser
-l hidden="true"
klausmeyer/docker-registry-browser
Wouldn't it be nice if manifests/images without any tags are hidden on the WebGUI? Currently the only way to remove empty manifests is to delete the folders in the repository's filesystem. On redis it would be more complicated...
I agree it would be much nicer to don't show them.
The issue currently is that I don't have the information if an image has any tags in the API call I am doing on the list view. In order to implement that I'd have to do an additional call per image in the list which isn't the best idea.
A workaround I was using in our private registry was running the garbage collection in a cronjob. This of course did not solve the "empty" images shown in the UI ad-hoc but at least after the next GC run they were gone.
See: https://docs.docker.com/registry/garbage-collection/
Sure, GC is a must have. But handling the view of empty images/manifests should be an option. Why isn't it a good idea to do additional call for every image? Its just a json what you're asking for. If it's empty, no tags... Sure, in case of a slow repo, it makes your app slower but much more comfortable.
As I said, you can make it optional to let the useres do the choice.
Why isn't it a good idea to do additional call for every image? Its just a json what you're asking for.
I'm just thinking about a registry with a lot of images. Currently the registry browser will show up to 100 of them per page. So in this case we'd have 101 API calls to just show one single list of images. Those API calls could be partially parallelized I assume but still this could take (to) long to render the page - maybe something one could test to see if it's just a theoretical issue.
Another issue is the mentioned pagination. If we filter out empty images on application side instead of having the API to exclude them we can't have a predictable behavior about how many images are shown on one "page".
In general I'd love to give it a try and implement it to see how it behaves but it's always a concern of time. I'll keep this as a feature request around and if someone would like to help I'm happy to accept pull requests.