5 ms·
Or you could, you know, host a Docker registry and reupload those images to something you control. Worst case scenario, in 30 days, nothing is gone from Docker
by ohgodplsno 4y ago
Or you could, you know, host a Docker registry and reupload those images to something you control. Worst case scenario, in 30 days, nothing is gone from Docker and you can just spin it down.
Your job as an SRE is not to look at things and go "oh well, nothing we can do lol".
- dbingham 4y agoYes, that involves ripping out Docker Hub everywhere. It's a significant chunk of work, not something easily fit into 30 days on a team that is already strapped for resources with more work than we can do.
- mysterydip 4y agoI'm not familiar with how Docker works, so forgive the ignorance. I thought the point of docker images was portability? Is it not just taking the references and pointing to a new instance under your control?
- creshal 4y agoI'm not too familiar with docker myself, but gitlab's selfhosted omnibus includes a container registry that Just Works™ for our small team.
- friendzis 4y agoMost production workloads do not use docker directly, but rather use it as sorts of "installation format" that other services schedule (spin up, connect, spin down, upgrade). One of typical defaults is to always try and pull new image even if requested version is available in node-local cache. On one hand it prevents issues where services would fail to start on certain nodes in the event of repository downtime. On the other hand it blocks service startup altogether. With such a set up availability of registry is mission critical for continuous operation. Some people think it is a perfectly reasonable idea to set up defaults to always pull, point to latest version and not have local cache/mirror. Judging from the number of upvotes on OP, depending on third party remote without any SLA to be always available for production workloads seems to be the default.
- Faaak 4y agoSetting up harbor as a docker proxy-cache is actually quite simple
- bushbaba 4y agoThat’s unplanned work. There’s other work needing to be done as well.
- ohgodplsno 4y agoAnd a sudden fire is also unplanned work, but that's still your work. If this is such a threat, then maybe shift priorities around.
- mynameisvlad 4y agoAre we not allowed to complain about unnecessary unplanned work being foisted on us with 30 days notice? That seems like an entirely relevant complaint for this forum but from your first reply, you’re acting like somehow it’s the greatest offense in the world that someone pointed this out.
- ohgodplsno 4y agoCome on, 30 days notice is a walk in the park. Additionally, OP was the one complaining that changing a few URLs and eventually spinning up a new server. It's quite literally a one day or two job, unless you're at a company the size of Amazon (in which case, luckily for you, you're not the only SRE, so it's still just a few days). > The best I can come up with, at the moment, is waiting for each organization to make some sort of announcement with one of "We've paid, don't worry", "We're migrating, here's where", or "We've applied to the open source program". And if organizations don't do that... I mean, 30 days isn't enough time to find alternatives and migrate. This is the original comment. The best they can come up with is... do nothing and wait to see if the smoke turns into a fire ? I've seen better uses of time. 30 days is enough time to find an alternative, migrate _and_ get regular coffee breaks too.
- mynameisvlad 4y ago30 days is nowhere near enough times for people with real jobs that have other things to do rather than drop everything to do this. Once again, completely needlessly. You’re making a mountain out of an entirely valid complaint. Quoting your own profile, stay mad.
- fieldcny 4y agoi didn't read it as that, they were stating the realities, assumptions were made, those assumptions are now invalid, they are working on alternatives, 30days is a short deadline for something like this and docker as an organization is behaving poorly. all of that seems pretty true, and frankly no one should support a company that does something like this. I get they need to figure out how to make money, but time has shown the worst way to do that is to screw over customers or potential customers. I like the poster will never trust docker, and will never use their tooling or formats, pod-man all the way.
- unilynx 4y agoEarlier events already had us slowly switching out docker for pod man, and the tooling is more similar than I had expected. Half of the work is ensuring the images are explicitly prefixed with docker.io/ And this week it turns out that makes the now problematic spots a lot more greppable
- hoherd 4y agoImagine you shipped software that included references to docker hub images. That software will no longer work if any of the referenced images are deleted from docker hub. This will be the case with any helm charts that reference images that are deleted from docker hub. Some of those charts will not have variables that let you override the docker images and tags, so some of those will not be usable without creating a new release. This is one of the primary reasons to vendor your third party docker images into a docker registry that you control.
- aprdm 4y agoYes vendor them all too.
- account42 4y ago[flagged]
- ohgodplsno 4y ago"Don't release software that can pull code from random services on the internet then execute it without making that configurable" has been standard since the internet was available, just about. Vendor your helm charts if they are production critical. Vendor the docker images if they are production critical. Vendor the libraries if they are critical. As an added bonus, you even help making a saner internet where you don't pull left-pad three billion times a month.
- planetafro 4y agoThis exactly. We have pipelines designed specifically for this reason. We pull, patch, and perform minor edits to images we use. We then version lock all-the-things for consistency. Not saying this is good news, but in the Enterprise, you have to plan for shit like this.