Docker Hub Registry is down
status.docker.com
Docker Hub Registry is down
1–10 of 35 posts
Re: Docker Hub Registry is down
#2uuugh. was just about to do some testing
Re: Docker Hub Registry is down
#3What's the best way around this kind of outage?
Re: Docker Hub Registry is down
#4What's the best way around this kind of outage?
Have the ability to build containers on demand from source as well as host your own repo.
Re: Docker Hub Registry is down
#5More confidence for the folks at Docker Inc.
Re: Docker Hub Registry is down
#6What's the best way around this kind of outage?
1) You can run your own pull-through cache[0]
2) You can use a different registry
3) Run something like kraken[1] so machines can share already-downloaded images with eachother
4) If you need an emergency response, you can docker save[2] an image on a box that has it cached and manually distribute it/load it into other boxes
0: https://docs.docker.com/registry/recipes/mirror/
1: https://github.com/uber/kraken
2: https://docs.docker.com/engine/reference/commandline/save/
Re: Docker Hub Registry is down
#7What's the best way around this kind of outage?
pull-through mirror with tons of disk
Re: Docker Hub Registry is down
#8What's the best way around this kind of outage?
Maintaining your own registry as a cache.
Re: Docker Hub Registry is down
#9What's the best way around this kind of outage?
Have the ability to build containers on demand from source as well as host your own repo.
Realistically, it's probably a cache/mirror.
If you can't build a deploy a new version of your app, you can probably live with it and grab a cup of coffee.
If you server fails over and your new server can't pull the current image, your app is potentially down, and that's a lot worse.
The math you do here is the cost of wasted time versus the cost for you to run your own registry with better uptime.
Re: Docker Hub Registry is down
#10Earlier quoted context omitted.
Have the ability to build containers on demand from source as well as host your own repo.
Realistically, it's probably a cache/mirror. If you can't build a deploy a new version of your app, you can probably live with it and grab a cup of coffee. If you server fails over and your new server can't pull the current image, your app is potentially down, and that's a lot worse. The math you do here is the cost of wasted time versus the cost for you to run your own registry with better uptime.
If you're an enterprise, you're likely already running Nexus, Artifactory, or some other artifact manager. The additional overhead to store containers in these systems is so close to zero, we can round down for our purposes. It's all blobs and SHA hashes anyway. Storage is cheap.
If you're not an enterprise, fall back to your cloud provider's container registry (which is likely backed by highly durable and reliable storage; AWS ECR & S3 for example). It's likely you already are using Jenkins or some other runner to build your own containers (and if you're not setup to do so with your CI pipeline, you should be); it's trivial to support caching to your in house cloud provider registry as part of the container build/retrieval/deployment process. This functionality is a handful of properly written Jenkins jobs based on my experience.
I'm not trying to avoid going to get a coffee while you wait for external provider interfaces to settle when your systems are nominal. I'm trying to avoid those moments where you absolutely need to deploy an existing or updated container and can't (which you mention in your comment). Critical infra requires redundancy. Container storage is critical infra when part of a deployment process. One cannot say, "Sorry engineering, that hotfix can't go out until the registry is back up. See you in 30. exit stage right to coffee shop" in most environments.
EDIT: Also consider Docker's finances are precarious and it's possible they're going to suddenly go dark. Plan accordingly.
Disclaimer: Previously infra/devops engineer.