[TuringNYC]

Someone would have to support it 24x7 and we could never get the uptime of DockerHub/ACS/ECS. Since a Production k8s deployment could spin up an instance at any time of day, some type of 5-9 or at least 4-9 uptime is pretty important.

[908B64B197]

I see.

I guess you could still fall back to the main package source if the local mirror is down.

[mschuster91]

As long as you're not doing push stuff:

1) set up a series of N docker registry mirrors in pull-through mode (https://docs.docker.com/registry/recipes/mirror/, it's as simple as "docker run --rm --name registry -d -p 5000:5000 -e REGISTRY_STORAGE_DELETE_ENABLED=true -e REGISTRY_PROXY_REMOTEURL=https://registry-1.docker.io -v /mnt/persistentdata/registry:/var/lib/registry registry")

2) expose them on the same domain name (multiple A records, loadbalancers, whatever you want)

3) set them as mirrors in each machine's docker daemon

In case one of your mirrors go down, take them out of the DNS/LB rotation. That's it.

[wmf]

Why is no one talking about this solution?

[ArchOversight]

Cause users still need to update where they are pulling from.

There'd need to be a way within docker to alias to the new URL so that what normally would go to docker hub ends up pulling from the mirror.

[mschuster91]

No they do not, that is the entire beauty of the pull-through mirror. For user code, as long as they keep referencing only to Dockerhub images, nothing needs to be changed (edit: except Gitlab CI configurations using docker:dind, which needs to be informed about the mirror).

The only downside is, as said, that it can't cache third party repos (quay.io comes to mind for people involved in k8s). For these, one has to mess with the resolv.conf and self-signed HTTPS certs for the Docker registry mirror.