4 ms·

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
- Qerub 6mo ago
  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 https://www.redhat.com/en/blog/introduction-ubi-micro published in 2021)
  - fhn 6mo ago
    great. Now I have to install and learn another tool when having yum inside the container will just work?
    - appcustodian2 6mo ago
      Not just that but it will probably break later and ruin everything
- jt2190 6mo ago
  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.
lokar 6mo ago
You don’t even need most of the files in the packages. Just pull out the files you need.

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
Qerub 6mo ago
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 https://www.redhat.com/en/blog/introduction-ubi-micro published in 2021)
- fhn 6mo ago
  great. Now I have to install and learn another tool when having yum inside the container will just work?
  - appcustodian2 6mo ago
    Not just that but it will probably break later and ruin everything
jt2190 6mo ago
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.

lokar 6mo ago

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