31–35 of 35 posts
Earlier quoted context omitted.
Being paranoid helps. My pipelines never pull images from the hub, I always store those locally.
do you have some kind of a maintenance routine that pulls image updates? you can end up with ancient docker hub images, because without --pull when compiling docker image, docker build won't pull base image updates by default
Regular reminder that Docker Hub is not really an enterprise registry with an SLA. You should use pretty much anything else for serious applications that rely on pulling images in the hot path (such as auto-scaling up).
So my CI environment requires access to other docker images, all hosted on Docker Hub. Seems like the tech giants should load balance these images for the good of the Internet to provide some decent redundancy and for my sanity at 11.30pm.
Rule #1 Host your own stuff, never rely on others.
Rule #2 automate everything
Earlier quoted context omitted.
yeah there's a variety of "free at point of use" services driving the Internet and, sooner or later it seems likely there will need to be a change in how they're funded. It's not just Docker hub, there's services like the various Programming language package repos (npm, rubygems etc) and the Linux distro package repos. I would have had Github in that category, but now it's owned by MS, presumably they don't have many…
Github used to be in their own colo on their own bare metal. I'm not sure if they've been pushed into Azure cloud as part of the MS acquisition, but either way Github isn't paying cloud retail ($$$) for their bandwidth, and it's likely sustainable.
Earlier quoted context omitted.
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…
The opinion I gave pretty much would help you define what is critical.
Every single smart enteprise should be able to build from source, push to a registry and deploy via a pipeline defined in source control. This likely gives you most of the DR you need, and it also helps you work as part of a team.
However, when you take these decisions you should be able to quantify why. You can always spend more money on more 9s and tighter SLAs, but at some point you need to draw a line in the sand and call it good enough.
For a small startup, that might be before running their own registry, for a large ecommerce website it's probably after. Humorously, a tech first startup would likely do it, whilst a sales first established business probably won't, because neither of them are really quantifying their efforts.
Disclaimer: Also do infra and devops. These are concepts from the SRE book, though I don't use the SRE terms because I can't remember them off the top of my head. Interestingly, the book publishes how google add errors into some products, so people don't rely them unsustainable relability attribuites.