Future of this project?

[devantler]

@rpardini this project is quite awesome, and to my knowledge the only viable solution for doing mirror registries with one container. We are using the registry, but are encountering some issues with IPV6 etc on some systems. I see a lot of the community have tried to solve issues including ours in e.g. https://github.com/rpardini/docker-registry-proxy/pull/130/files, but to no avail, as the project seems abandoned.

Can you share some information on whether it has been abandoned, and if so why? Are you aware of other and better solutions, or are you interested in new maintainers to keep the project afloat? ❤️🚀

[rpardini]

Hey @devantler -- I personally haven't had much use for this project, since for quite a few years now containerd has supported multiple registry mirrors. This project seems to be useful for folks somehow still using Docker/moby, and in my experience it still works fine.

The issues most people raise seem to be indeed related to (usually very specific, mostly enterprise proxy/funky networking/non-standard setups) DNS and IPv6.

I simply can't spare the cycles to address those edge cases, as the changes proposed need testing in many diverse scenarios and against many different upstream registries, all of which behave slightly differently. The main concern is that the project works as-is for 90%+ of users, and there's a very high chance those PRs might break them.

My suggestion: fork the project, merge the PRs you need, test it under the common and uncommon scenarios and produce evidence. I doubt you, or anyone, is willing to do so, but if I'm proven wrong I'd gladly pull from that fork.

[devantler]

Thanks for your insights! You're correct that I probably can't find time to take on the workload required to ensure the changes work for every edge case. My primary goal was to solve my specific needs. I found a fork that published an image (moonbuggy2000/docker-registry-proxy:latest) solving the IPv6 issue, which is the only problem I have encountered so far, so that works for me for now.

For context I find the solution usable as it makes it possible to have one container act as a mirror and cache for multiple upstreams. To my knowledge containerd requires one instance of registry:2 per configured mirror in containerd. If that is incorrect, I would love a link to better understand what you mean with "containerd has supported multiple registry mirrors". Sounds like there is a better way, that I am not aware of 👀

[rpardini]

requires one instance of registry:2 per configured mirror

That's a registry:2 self-imposed limitation, as that is also originally from Docker, Inc.
Something like Harbor can support multiple mirrors in a single instance.

[devantler]

Ahh now I follow. We tend to have a fully working local cluster in our team, so being able to mirror registries and cache images via Docker is quite important to us. We use this setup locally and in CI, so we are able to test the cluster configuration works prior to it being promoted to dev, test and prod. So depending on Harbor is not really an option, as it would create a hen after the egg problem (harbor needs to exist prior to proxying images). For insight we do use Harbor a lot in non-local environements :-)

For now this project handles that use case really well with Docker, primarily because registry:2 has that limitation.

But thanks for sharing your thought, it makes a lot of sense!