I have a private docker registry that I’m using for my own images. I would like that the container that run this images (via docker-compose) get updated immediately, when I push a new version.
I know that there are Watchtower (https://containrrr.dev/watchtower/) and Diun (https://crazymax.dev/diun/), but these containers are only polling in a defined interval (I’m using watchtower now, but it is not as fast as I like even with a poll every minute).
I found that the docker registry is sending notifications when a container is updated (https://docs.docker.com/registry/notifications/) and was looking for a service that uses this. But I didn’t found any tool, expect for a Jenkins Plugin (https://github.com/jenkinsci/dockerhub-notification-plugin). Am I looking at the wrong places or is there just no tool that works with the notifications from the registry?
2
Answers
I think you have to look at the problem from a different angle. If you shift your focus from containers, you will notice that GitOps might be the perfect fit. You can achieve the same thing with your CI/CD pipeline that trigger a redeployment.
If you want to stick with containers only, I can recommend taking a look at Harbor that can call a Webhooks after a push. See docs (https://container-registry.com/docs/user-manual/projects/configuration/webhooks/)
Since webhooks aren’t part of OCI’s distribution-spec, any solution that implements this will be registry specific. That means you won’t be able to easily change registries in the future without breaking this implementation. Part of the value of registries and the standards they use is allowing portability, both of the images, and of tooling that works with those registries. What works on distribution/distribution specific APIs may not work on Nexus, Artifactory, or any of the cloud/SaaS solutions like Docker Hub, Quay, ECR, ACR, GCR, etc. (I’m leaving Harbor out of this list because they are based on distribution/distribution, so that’s the one registry where it will probably work.)
If you want the solution to be portable, then it either needs to be designed into a higher level workflow (e.g. the same CI pipeline that does the push of the image triggers the deploy), or you are left with polling which a lot of GitOps solutions implement. Also realize that the S3 backend many registries use is eventually consistent, so with a distributed/HA registry implementation, trying to pull the image before the data store has had a chance to replicate may trigger race conditions.