6 ms·
All docker containers should have been like that. apt-get update in a docker build step is an anti pattern.
by dev_l1x_be 6mo ago
All docker containers should have been like that. apt-get update in a docker build step is an anti pattern.
- DuncanCoffee 6mo agoI know it's an anti-pattern, but what is the alternative if you need to install some software? Pulling its tagged source code, gcc and compile everything?
- rowanG077 6mo agoWith a binary cache that is not so bad, see for example what nix does.
- Pay08 6mo agoI don't really see how that's different from a normal binary install of a reproducible package. Especially with the lacking quality of a lot of Nix packages.
- rowanG077 6mo agoIt's not if you can pin the package. It gives you reproducable docker containers without having to rebuild the world. Wasn't that the entire question?
- bandrami 6mo agoIf you're in a situation where you want reproducibility you're using nix to build your own packages anyways, not relying on their packages
- bennofs 6mo agoBoth Debian and Ubuntu provide snapshot mirrors where you can specify a date to get the package lists as they looked at that time.
- bluGill 6mo agoWhich is only useful for historical invesigation - the old snapshot has security holes attackers know how to exploit.
- lloeki 6mo ago> the old snapshot has security holes attackers know how to exploit. So is running `docker build` and the `RUN apt update` line doing a cache hit, except the latter is silent. The problem solved by pinning to the snapshot is not to magically be secure, it's knowing what a given image is made of so you can trivially assert which ones are safe and which ones aren't. In both cases you have to rebuild an image anyway so updating the snapshot is just a step that makes it explicit in code instead of implicit.
- bluGill 6mo agowhere does the apt update connect to? If it is an up to date package repo you get fixes. Howerer there are lots of reasons it would not. You better know if this is your plan.
- lloeki 6mo agoYeah that's yet another annoying thing to consider Also I'm tired of doing these hacks: # increase to bust cache entry RUN true 42 && apt update Pinning to a snapshot just makes so many things easier.
- foresto 6mo agoYou get fixes that were current at docker build time, but I think GP is referring to fixes that appear in the apt repo after your docker container is deployed. If you've pulled in a dependency from outside the base image, there will be no new base image version to alert you to an update of that external dependency. Unless your container regularly runs something like apt update && apt list --upgradable, you will be unaware of security fixes newly available from apt.
- kandros 6mo agoCopying from another image is an under appreciated feature FROM ubuntu:24.04 COPY --from=ghcr.io/owner/image:latest /usr/local/bin/somebinary /usr/local/bin/somebinary CMD ["somebinary"] Not as simple when you need shared dependencies
- liveoneggs 6mo agopretend you don't do it and add your extra software to the layer above
- dev_l1x_be 6mo agobase image software component image both should be version pinned for auditing
- Filligree 6mo agoRun “nix flake update”. Commit the lockfile. Build a docker image from that; the software you need is almost certainly there, and there’s a handy docker helper.
- klodolph 6mo agoRecently I’ve been noticing that Nix software has been falling behind. So “the software you need is almost certainly there” is less true these days. Recently = April 2026.
- sestep 6mo agoAre you referring to how the nixpkgs-unstable branch hasn't been updated in the past five days? Or do you have some specific software in mind? (not arguing, just curious)
- klodolph 6mo agoIt’s a variety of different software that just isn’t updated very often. I don’t mind being somewhat behind, but it seems like there are a lot of packages that don’t get regular updates. It’s okay to have packages that aren’t updated, but those packages should be clearly distinguishable.
- Pay08 6mo agoThat's been an issue for years from my impression of the state of NixOS. There are other problems too, like a lot of open source packages doing straight binary downloads instead of actually building the software.
- PunchyHamster 6mo agooh, great, adding more dependency, and one that just had serious security problem
- hexa555 6mo agoas if other sandboxing software is perfect
- codethief 6mo agoUse https://github.com/reproducible-containers/repro-sources-list.sh https://github.com/reproducible-containers/repro-sources-lis...
- malikolivier 6mo agoThis is to solve such issues that I am using and running StableBuild. It is a managed service that keeps a cached copy of your dependencies at a specific time. You can pin your dependencies within a Dockerfile and have reproducible docker images.
- schonfinkel 6mo agoI don't wanna be that guy but... NIX FIXES THIS.
- dijit 6mo agoSo does Bazel. :p
- evanjrowley 6mo agoadding to the list, one exotic approach to this problem is stagex https://codeberg.org/stagex/stagex https://codeberg.org/stagex/stagex
- bluGill 6mo agoYou are screwed either way. If you don't update your container has a ton of known security issues, if you do the container is not reproducable. reproducable is neat with some useful security benefits, but it is something a non goal if the container is more than a month old - day might even be a better max age.
- dev_l1x_be 6mo agoI update my docker containers regularly but doing it in a reproducible, auditable, predictable way
- tom1337 6mo agoCould you explain how you achieve this?
- oefrha 6mo agoChainguard, Docker Inc’s DHI etc. There’s a whole industry for this.
- beart 6mo agoIf you are on github/gitlab, renovate bot is a good option for automating dependency updates via PRs while still maintaining pinned versions in your source.
- dev_l1x_be 5mo agohave a multi layer build system where there is version of each layer. Example - linux base: kernel + libc + some low tooling - jvm base: adding the JRE/JDK you need - your application version
- tosti 6mo agoWhy is there a need for a package manager inside a container at all? Aren't they supposed to be minimal? Build your container/vm image elsewhere and deploy updates as entirely new images or snapshots or whatever you want. Personally I prefer buildroot and consider VM as another target for embedded o/s images.
- bandrami 6mo agoThis has been a solved problem for over two decades now with Nix but people can't be asked
- dev_l1x_be 6mo agoIt has been solved even without Nix for a long time, just laziness is probably why we are not doing it
- rascul 6mo agoI disagree with that as a hard rule and with the opinion that it's an anti-pattern. Reproducible containers are fine, but not always necessary. There's enough times when I do want to run apt-get in a container and don't care about reproducibility.
- mikedelago 6mo agoI agree with your opinion. Reproducible can sometimes be a goal, but repeatable is always important. I do think for this case specifically (base images for a specific distro), they should be reproducible.
- cpuguy83 6mo agoThe problem is distros often remove older versions from the repo as soon as the new version is available. Granted there is an archive that you can pull from.
- codethief 6mo ago…unless you use https://github.com/reproducible-containers/repro-sources-list.sh https://github.com/reproducible-containers/repro-sources-lis... . I've been using it for a while and it's worked really well for me!