9 ms·

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

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 6y ago
I see. I guess you could still fall back to the main package source if the local mirror is down.
- mschuster91 6y ago
  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/ 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 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 6y ago
    Why is no one talking about this solution?
    - ArchOversight 6y ago
      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 6y ago
        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.

908B64B197 6y ago

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

mschuster91 6y ago
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/ 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 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 6y ago
  Why is no one talking about this solution?
  - ArchOversight 6y ago
    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 6y ago
      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.