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.
Just say no to :latest
31–40 of 135 posts
Re: Just say no to :latest
#32Re: Just say no to :latest
#33As 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
#34Same with pip/Python. Recucing dependencies to a bare minimum helps long term survival of software.
Lockfiles (poetry.lock, Pipfile.lock etc.) solve the survivality problem for the most part.
Re: Just say no to :latest
#35If 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
#36Ah, 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
#37This 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…
(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
#38Re: Just say no to :latest
#39There 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
#40Earlier 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.