Live data from Hacker News

Just say no to :latest

platformers.dev

31–40 of 135 posts

Re: Just say no to :latest

#31

Earlier quoted context omitted.

I just said that use latest exactly to avoid this issue.

You said to use it for development. But I don't use Artifactory so maybe you meant to use the latest for production also, if it passes the build.

Having robust process requires some tools. Artifactory (or any other private Docker registry) is one such tool.

Re: Just say no to :latest

#33
>It breaks one of the core requirements of continuous delivery: reproducible, idempotent builds

As long as you are able to look up what latest evaluated to during the build you retain most of the benefits while getting automatic updates.

Re: Just say no to :latest

#34

Same with pip/Python. Recucing dependencies to a bare minimum helps long term survival of software.

But it may hinder short-term survival (because you're spending time reinventing the wheel instead of building competitive product).

Lockfiles (poetry.lock, Pipfile.lock etc.) solve the survivality problem for the most part.

Re: Just say no to :latest

#35
Forget for a second the security concerns -

If you lose :latest, and the build breaks, you need to spend unexpected time fixing the build, for whatever reason that :latest broke it, in order to continue with the business objective that you were actually tasked to do. Essentially, you have InfoSec muscling in and demanding, by the most coercive way possible, that Thou Shalt Not Do Your Job Without Bowing Before Me. Who cares what the business wanted? Who cares about predictable schedules? Who cares about delivering for a customer by a point in time which was promised to the customer?

This isn't the way to promote a healthy culture in the company. Nobody should get immediate and total veto rights. In the real world, healthy organizations balance between different stakeholders, and once a path is set, everybody shuts up and executes. The right place to make a stand for your interests is in the stakeholder meeting, not the deployment pipeline.

Re: Just say no to :latest

#36
> In reality, you probably need a mechanism to enforce tag immutability: e.g., your own registry mirror.

Ah, that sounds so trivial. And yet it is very much not. Aside from the hot mess that is the docker registry daemon, some tags are meant to be rolling. You absolutely do not want them cached.

Re: Just say no to :latest

#37

This is always a balance. The moment you pin to a specific version you need to have a process in place to ensure you regularly upgrade to avoid introducing vulnerabilities in your production system. Throughout my career I have seen many cases where certain software still runs on ancient versions as the team originally maintaining it is no longer around (e.g. reorganisations or lay-offs). It is always hard to convince…

I've used Maven version ranges to great effect... ...only projects that actually observe semver.

(Jackson, take a bow for doing so with your patch releases. I wouldn't use it for your 'minor' releases though.)

Re: Just say no to :latest

#39
There are containers that I want ASAP to be updated to the latest version which likely contains all known security fixes. I consider the risk of missing an update for a - then public - security problem greater than the risk of getting a new, still unknown security risk. While I am trying to, I will not have the time to be really on top of all updates at all times. And I am more comfortable with a container breaking than with a container missing an important update.

There are aspects where reproducibility is key, but thats only a subset of all containers on our network. And on my home network it’s none at all.

Re: Just say no to :latest

#40
post #5

Earlier quoted context omitted.

From the original article > This brings up an interesting side point, in that Docker Hub and most other registries allow mutable tags by default. So nginx:1.21.6 might not be the same image today as it was yesterday. In reality, you probably need a mechanism to enforce tag immutability: e.g., your own registry mirror, or referring to images by SHA)

yeah, well, i stopped reading when i saw that "GOOD" example. it's not. and that isn't a "side point", that's the most critical point for preserving security and reproducibility of builds.

It's literally the line that follows that example. Why do you think it's useful to comment when you haven't even read the topic of discussion. You're like a person not reading the book at a voluntary book club. If you don't want to read it, just don't show up.
Post reply on HN