4 ms·
After Docker announced rate limiting for the hub this was an anticipated move. Was just the matter of time. The only recommendation to everyone: move away or d
by nrvn 4y ago
After Docker announced rate limiting for the hub this was an anticipated move. Was just the matter of time.
The only recommendation to everyone: move away or duplicate.
One of the strategies I am yet to test is the synchronization between gitlab and github for protected branches and tags and relying on their container registries. Thus (at least) you provide multiple ways to serve public images for free and with relatively low hassle.
And then for open source projects’ maintainers: provide a one command way to reproducibly build images from scratch to serve them from wherever users want. In production I don’t want to depend on public registries at all and if anything I must be able to build images on my own and expect them to be the same as their publicly built counterparts. Mirroring images is the primary way, reproducing is the fallback option and also helps to verify the integrity.
- acdha 4y ago> Mirroring images is the primary way, reproducing is the fallback option and also helps to verify the integrity. I suspect the latter will become more common over time. I can count on no fingers the number of open source projects which I’ve encountered which have production-grade container images. Once you need to think about security you need to build your own containers anyway and once you’ve done that you’ve also removed the concern of a public registry having issues at an inopportune moment.
- phillebaba 4y agoSome self promotion but I have built a project that aims to solve some of these issues in Kubernetes. https://github.com/xenitAB/spegel https://github.com/xenitAB/spegel I have avoided a couple of incidents caused by images being removed or momentarily not reachable with it. It would at least mitigate any immediate issues caused by images being removed from Docker Hub.