[krab]

Why not decentralized? Debian (for example) can provide one or two servers with a gigabit line. That's going to be quite slow to download during every CI build. Therefore, your CI provider would have a caching proxy registry. You get fast service, upstream doesn't need a ton of bandwidth.

[sirius87]

Docker images are often tied to CI runs. So a Github action is configured to "bake" a docker image that saves the image to Github Container Registry and a CI platform is triggered to pull the image and run tests immediately thereafter. Imagine this happening on every Git commit in a certain branch.

Often, there isn't time for an image to be pulled from a mirroring serving.

[krab]

I meant the base images. If you're pushing your own images, then you can use any service you want (and pay for it). Since the traffic doesn't need to go through the internet at all, the bandwidth cost to Dockerhub would be irrelevant.

[sirius87]

Base images are already available on different container image hosting platforms. For instance, ubuntu is here [1] on Amazon ECR. So it's matter of updating Dockerfiles to use them.

There again there's the question of finding image sources you can trust to be updated and secure. Docker Hub has a "Docker Official Image" tag for critical base images that are managed by each community.

[1] https://gallery.ecr.aws/ubuntu/ubuntu

[krab]

That's my point - that it's entirely possible to not rely on the single central repository.

Re. finding the sources, a central namespace may still be useful, hence the use of caching proxies.