Maintaining docker containers up to date can quickly become time consumming compared to good old distribution packages.
I use both and I'm still trying to find a good combination of tools to reproduce the "package" and unattended upgrades UX where things are safely kept up to date automatically.
Just say no to :latest
51–60 of 135 posts
Re: Just say no to :latest
#52This 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 also seen the same. As soon as people start locking versions, that code is no longer updated and nobody will change it, because it's extra work to do so. I personally think running latest is the best thing to do. And if something fails, you downgrade it temporarily until the latest work again. It's pretty much opposite to what is recommended, and it's just the best solution in my opinion.
My company locks versions, but dependabot is configured on all of our repos. It automatically creates PRs to bump versions, and if CI passes for minor/patch bumps they get automatically merged. This takes a lot of the hassle out of the problem. For major bumps, a manual approval is required, but they happen infrequently enough that it's not a lot of work.
Re: Just say no to :latest
#53Earlier quoted context omitted.
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.
i suggest you to read my comment again, because so far what you've said applies to you more than to me.
Re: Just say no to :latest
#54Earlier quoted context omitted.
> you have InfoSec muscling in and demanding, by the most coercive way possible, that Thou Shalt Not Do Your Job Without Bowing Before Me. InfoSec is not optional.
Of course it's not. But it's not King, either.
I could see it argued that in $CurrentYear, any information oriented company that doesn't put InfoSec as their #1 priority, is just asking to be pwned. It's not an if, but a when and to what extent.
Re: Just say no to :latest
#55In practise using latest or just the major version has caused far less wasted effort for our team than scrambling to update versions because of some newly discovered CVE.
It's a problem in frontend builds because js libs are quite poorly behaved so we fix more there but any backend stuff, be it alpine / debian base images, jvm libs, toolchains so on we've not had an issue with specifying only major versions.
Dogmatic rules are wrong 100% of the time.
Re: Just say no to :latest
#56This 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…
It's better to only change one thing at a time, not to get your dependencies updated as a surprise when you're trying to update something else. Besides, if the dependencies aren't pinned in version control, how can you answer a query like "On this date last year, what version were we running?"
I am using AWS ECS as a Docker repo with releases using the image hash (as well as a server). If you want to rollback to a certain time, you just identify the appropriate Docker image tag, and restore the Docker you used at that time in your development environment.
To give an example, we got stuck on Python Pandas 0.24.2 for two years when the Pandas 1.0 upgrade happened. At the time we pinned the version as one job was failing. With COVID priorities naturally changed and this was forgotten. When normality returned we suddenly had to upgrade 10 jobs to Pandas 1.2.x, a very painful migration that took one Engineer 4 weeks of testing. In hindsight it would have been far better to upgrade this one job, as it would have only taken a few hours.
Again it is a trade off. Having unexpected dependency changes can be cumbersome when you are releasing a small change. However, getting senior management to agree of weeks of upgrade testing can be challenging as well. My natural preference is not to pin versions, unless I absolutely have to.
Re: Just say no to :latest
#57Yes, and no.
This does mean that you have to actively manage your versions for any security fixes. Which you should be doing anyway. However when upgrading or patching you have to check in a bunch of places to make sure the update was effective.
As someone mentioned else where, its better to pin to major versions rather than specific. You'll need to make sure you have decent integration tests and monitoring though. I mean you have that already right?
Re: Just say no to :latest
#58Depends on usage case. At home I :latest everything. The work of constant adjusting tags to bring it up to date is more hassle than the risk of something breaking.
Prod stuff....yeah best to pin it for supervised upgrades
Re: Just say no to :latest
#59Call me stuffy but I argue for writing your own Dockerfiles, all from one or a small number of common base images (e.g. scratch+debian, or what have you), served from your self-hosted registry.
If you want to use some provided official image for vendored software, just port it over.
Then you tie the build+push into your pipeline however suits your org, be it fully manual or end-to-end CI with regular rebuilds.
This solves several issues mentioned elsewhere in the thread. As a bonus you won't be affected should docker.io or quay have issues or make breaking changes.
Re: Just say no to :latest
#60Earlier quoted context omitted.
By convention npm packages are not deleted or hijacked.
You do realize that NPM package versions already are immutable? Dunno since when though. Deletion is possible within limits but it also is with Docker. All the hashes in the world won't bring back a deleted image.
version numbers are never immutable. they are arbitrary labels that are created by some centralized authority and can be changed by that same authority.
artifacts being removed is much less of a problem as artifacts being spoofed with malicious content.