4 ms·

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

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.

chaps 6mo ago
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?
- arandomhuman 6mo ago
  Aforementioned security vulnerabilities don’t strike as a potential reason to you?
  - chaps 6mo ago
    Friend, considering the supply chain attacks going on these days, automatically updating everything, immediately, probably isn't the perfect move either.
    - askl 6mo ago
      Ignoring the real benefits of security updates to prevent the unlikely event of supply chain attacks sounds like a weird tradeoff.
      - chaps 6mo ago
        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.
    - bluGill 6mo ago
      You need to automatically update from a trusted source. That source better audit and update constantly. Which is hard.
      - LtWorf 6mo ago
        Stable distributions have security teams.
- pavon 6mo ago
  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).
  - chaps 6mo ago
    No, this is not always the case. Regulated industries pin their package versions and store those versions for pulling.
- AntiUSAbah 6mo ago
  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.
klodolph 6mo ago
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.
- AntiUSAbah 6mo ago
  Yes, how?
  - tosti 6mo ago
    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.
  - klodolph 6mo ago
    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/ https://xeiaso.net/talks/2024/nix-docker-build/) and Bazel (https://github.com/bazel-contrib/rules_oci 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.
  - jasomill 6mo ago
    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 https://github.com/containers/buildah/blob/main/README.md
zamadatix 6mo ago
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.
- AntiUSAbah 6mo ago
  I do not talk about multi-step container images. For example i run a gcs fuse driver, it has other dependencies apt 'just' resolves.

chaps 6mo ago

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?

arandomhuman 6mo ago
Aforementioned security vulnerabilities don’t strike as a potential reason to you?
- chaps 6mo ago
  Friend, considering the supply chain attacks going on these days, automatically updating everything, immediately, probably isn't the perfect move either.
  - askl 6mo ago
    Ignoring the real benefits of security updates to prevent the unlikely event of supply chain attacks sounds like a weird tradeoff.
    - chaps 6mo ago
      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.
  - bluGill 6mo ago
    You need to automatically update from a trusted source. That source better audit and update constantly. Which is hard.
    - LtWorf 6mo ago
      Stable distributions have security teams.
pavon 6mo ago
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).
- chaps 6mo ago
  No, this is not always the case. Regulated industries pin their package versions and store those versions for pulling.
AntiUSAbah 6mo ago
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.

klodolph 6mo ago

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.

AntiUSAbah 6mo ago
Yes, how?
- tosti 6mo ago
  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.
- klodolph 6mo ago
  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/ https://xeiaso.net/talks/2024/nix-docker-build/) and Bazel (https://github.com/bazel-contrib/rules_oci 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.
- jasomill 6mo ago
  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 https://github.com/containers/buildah/blob/main/README.md

zamadatix 6mo ago

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.

AntiUSAbah 6mo ago
I do not talk about multi-step container images. For example i run a gcs fuse driver, it has other dependencies apt 'just' resolves.