Hacker News Reader

Comment by AntiUSAbah | Hacker News Reader

So if i have a docker container which needs a handful of packages, you would handle it how?

I'm handling it by using a slim debian or ubuntu, then using apt to install these packages with necessary dependencies.

For everything easy, like one basic binary, I use the most minimal image but as soon as it gets just a little bit annoying to set it up and keep it maintained, i start using apt and a nightly build of the image.

View on HN

IMO—package manager outside the container. You just want the packages inside the container; the manager can sit outside and install packages into the container.

Yes, how?

With Red Hat's UBI Micro:

  microcontainer=$(buildah from registry.access.redhat.com/ubi8/ubi-micro)
  micromount=$(buildah mount $microcontainer)
  yum install \
      --installroot $micromount \
      --releasever 8 \
      --setopt install_weak_deps=false \
      --nodocs -y \
      httpd

(from https://www.redhat.com/en/blog/introduction-ubi-micro published in 2021)

great. Now I have to install and learn another tool when having yum inside the container will just work?

Not just that but it will probably break later and ruin everything

For the package management, it depends on the package manager, but most have some mechanism for installing into a root other than the currently running system.

Even without explicit support in the pacakage manager, you could also roll your own solution by running the package manager in a chroot environment, which would then need to be seeded with the package manager's own dependencies, of course (and use user-mode qemu to run pre- and post-installation scripts within the chroot in the case of cross-architecture builds).

Whether this yields a minimal container when pointed at a repository intended to be used to deploy a full OS is another question, but using a package manager to build a root filesystem offline isn't hard to pull off.

As for how to do this in the context of building an OCI container, tools like Buildah[1] exist to support container workflows beyond the conventional Dockerfile approach, providing straightforward command line tools to create containers, work with layers, mount and unmount container filesystems, etc.

[1] https://github.com/containers/buildah/blob/main/README.md

There have got to be a million ways to do this by now. Some of the more principled approaches are tools like Nix (https://xeiaso.net/talks/2024/nix-docker-build/) and Bazel (https://github.com/bazel-contrib/rules_oci). But if you want to use an existing package manager like apt, you can pick it apart. Apt calls dpkg, and dpkg extracts files and runs post-install scripts. Only the post-install script needs to run inside the container.

I may be a little out of touch here, because the last time I did this, we used a wholly custom package manager.

Docker recommends using multi-stage builds e.g. Stage one image has the package manager, stage two image omits it completely, leaving only the installed software.

apk and xbps can do this. You specify a different root to work in.

Most Makefiles allow you to specify an alternate DESTDIR on install.

You don’t even need most of the files in the packages. Just pull out the files you need.

The same way you may require something like cmake as a build dependency but not have it be part of the resulting binary - separate build time and run time dependencies so you only distribute the relevant ones.

I do not talk about multi-step container images.

For example i run a gcs fuse driver, it has other dependencies apt 'just' resolves.

Your question feels insane to me for production environments. Why aren't you doing a version cutoff of your packages and either pulling them from some network/local cache or baking them into your images?

I don't just run a java spring boot application. I run other things on my production system.

It doesn't matter much were i pull them from though, i only do this with packages which have plenty of dependencies and i don't want to assemble my own minimal image.

Aforementioned security vulnerabilities don’t strike as a potential reason to you?

Friend, considering the supply chain attacks going on these days, automatically updating everything, immediately, probably isn't the perfect move either.

You need to automatically update from a trusted source. That source better audit and update constantly. Which is hard.

Stable distributions have security teams.

Ignoring the real benefits of security updates to prevent the unlikely event of supply chain attacks sounds like a weird tradeoff.

A weird tradeoff but an increasingly important tradeoff to keep in mind nonetheless. Like I said, updating immediately isn't a perfect answer. But neither is waiting. I hope you're having this discussion, at least.

That local cache is often implemented as a drop-in replacement for the upstream package repository, and packages are still installed with the same package manager (yum,apt,pip,npm).

No, this is not always the case. Regulated industries pin their package versions and store those versions for pulling.

Reply on news.ycombinator.com