Hacker News Reader

Comment by tigrezno | Hacker News Reader

About the "apt upgrade". In major distributions, that's safe. They won't introduce major package versions, only minor (and security fixes).

It should be totally OK to upgrade the packages.

Also I don't get that it's advised to use "apt update" when you can't do "apt upgrade". What's the point??

View on HN

It's not entirely clear from the article but my guess would be that you should really update the repository + base dependencies in the base image, not the "application" image or whatever you wanna call it. But not the end of the world if you're not reusing that base image. Feels weird that an article on "Security Best Practices" would advise _against_ latest versions of your software, especially using apt as an example which is usually used in stable distributions (major version upgrades happens seldom) like Ubuntu/Debian.

But yeah, that last part doesn't make any sense. If you're not running `apt-get upgrade`, it doesn't make sense to run `apt-get update` as nothing is using the newly fetched data anyways...

Apt update just updates the cache of the package lists - /var/lib/apt/lists/ - based on your lists - /etc/apt/sources.list.d/. "upgrade" actually upgrades the code on the system.

`rm -rf /var/lib/apt/lists/*` in the same RUN decreases bloat and I think possibly decreases cache misses as well.

> and I think possibly decreases cache misses as well.

Unlikely, you'd still have misses because of stuff like file metadata mismatches (think modification times).

Base images usually ship with that done. `apt-get update` just undoes the good work of removing irrelevant lists.

Some base images do, but some don’t, and they update on their schedule rather than yours. Doing the update on your schedule is trivial, has no meaningful downside, and means it’s done and tested as quickly as you need.

Huh, TIL. I'll give that a try. Usually, that's the least of my problems. In my line of work, I'm often doing things which would likely horrify most webapp devs, like building a container with multiple conda envs in it. OTOH, most of these containers run on airgapped systems with petabytes of storage, so shipping a bit of bloat barely hurts the end user. But every time I do, I die a bit on the inside.

If you upgrade your packages during a build then inadvertently if 2 people build your Dockerfile at two distinct times they can end up with 2 different images. So rather than focusing on "we're using base-image:1.0.2" you need to start asking questions like "list all packages and versions and start comparing those".

If there's a security issue you need to rebuild your images anyway and optimally you have a system in place that represents images and their dependencies as some sort of dependency graph structure, so when you upgrade your base image all dependent images get rebuilt automatically.

Reply on news.ycombinator.com