I am thinking to make the following tool, but wanted to get opinions before I embark on this journey.
The tool builds container images.
The images are optionally distroless: meaning, they do not include an entire distro. They only include the application(s) you specify and its dependencies.
What else does the tool give you?
- the build tool uses a package manager to do dependency resolution, so you don’t have to manually resolve them like many docker files do. (NOTE: The package manager is not installed on the container image. It is only used by the build tool)
- uses gentoo’s portage to build the software from source (if not previously cached). This is helpful when you’re using versions of software that aren’t built against each other in the repos you download from
- allows specifying compile flag customizations per package.
- makes use of gentoo’s existing library of package build or install recipes, so that you only have to write them for uncommon apps rather than in every docker file.
I find it crazy that so many dockerfiles are doing their own dependency resolution when we already have package managers.
What do you think? Is this tool useful or am I missing a reason why it wouldn’t be?
So you want to build something like apko (alpine packages/repos, used in chainguard’s images) or rules_oci (used in google’s Debian-based distroless images) but for portage?
I think it’d be cool. Just keep in mind:
- Container scanning tools (like trivy), afaik, tend to look for a package db. Going distroless breaks them. I believe this is why chainguard generates a SBOM (software bill of materials).
- Container images are already de-duplicated, and often, the gains in pull times aren’t worth the additional debugging effort (for example, you won’t be able to have dig/curl installed without rebuilding and deploying the whole image, or even a bash prompt in most cases). They’re even more not worth it because lazily pulling OCI images is now a thing, though it’s in its infancy. See: eStargz and I believe dragonfly which uses nydus. More generally though, zstd:chunked will probably eventually become mainstream and default, which will all but eliminate the need for “minimal” starting images.
- If you wanted to go really small, there’s stuff like slim which makes tailor made images.
- Gentoo, afaik, doesn’t really do LTS releases, making it undesirable for server use, which is the main place containers are.
- Distroless containers don’t share common base images because they are normally scratch-built. This breaks image deduplication, leading to increased disk usage instead of decreased disk usage, and why I personally swapped off chainguard’s images.
Did not know about apko. I am not attached to distroless, just thought it was a nice to have. So apko might be a reason I don’t pursue this project anymore. Thanks for showing me!
Your comment is very insightful for other reasons too. Thanks a lot :)
Unless you specifically want ebuilds, take a look at nixpkgs dockerTools. It does everything you list here.
https://nixos.org/manual/nixpkgs/stable/#sec-pkgs-dockerTools
I had a feeling nixos would have something, but I avoided it because it seemed more than a day’s worth of learning (and also its a bit opinionated). But I will revisit it one day!
I think you’re missing the point of distroless by trying to make a distro out of an image based on distroless with a package manager.
The entire context of that image would be immediately lost and make absolutely no sense by introducing a package manager into it.
If you’re unfamiliar with combining portions of images as multi-stage builds, you may want to look into that to grasp the concepts better.
Another thing: not all containers are built with dockerfiles. You might want to get more familiar with how distroless images are built into the OCI-compliant sense, and the tools used therein.
What you’re describing not only already exists, it exists in the toolchain you mean to rewrite. It’s a hat on a hat, on another hat because it’s in containers.
Maybe if you described the problem you’re having, it might help others understand what you’re trying to solve for.
The package manager would not be part of the container image. The package manager is only used to build it. The container image will only include the packages the user specifies.
combining portions of images as multi-stage builds
That’s something I am making use of for this, actually :)
What you’re describing not only already exists…
Can you please give an example of a tool that can build a container image by being given only a list of packages it needs to have?
My tool would be as simple as doing something like this:
build-container --packages nodejs-20.1.1, yarn-4.2.2, some-app-i-made-1.0.0
And I would have a container that only has nodejs binary, yarn, and my own app. no package manager or any utils.
Yes. In your example, the base image is nodejs, which includes yarn. Then you copy your app into it with a COPY command and set the entrypoint to execute. Dead simple.
the base image is nodejs
Which has its own dockerfile. My proposed tool would allow using other images as base too, but that is not the problem it is solving.
copy your app
Well you’d have to have it compiled or built if that is required in your case. With my system, the build recipe would be a gentoo ebuild (shell-script-like) that you would just reference.
The example I gave is pretty simple, you’re right. Say in another case, you list the following packages:
nodejs, nginx, vpn-app(wireguard), some-system-monitoring-app, my-app
You could start with a nodejs base or an nginx base, and then write the steps to install the other. You’d also have to make sure to get all the deps if they have them.
You’re unlikely to find a ready image that has all what you want. But with my method, you can compose different ones however you like, rather than having to find an image that matches your exact use case.
Again, all you’re describing is just scripting tools that already exist together.
My question is “WHY?”. You’ve not been able to describe a problem that needs a solution. I’m seeing in these other comments that you’re just deflecting that question, so do you know what you’re trying to solve here?
Please demonstrate how the example I gave above can be done with common scripting tools, such it would mimic the declarative experience I described. I don’t think it is possible as you claim.
Can you please point to where I deflected any questions? I looked and could not find any instances of such.
I actually answered the question “why”, please refer to previous comments. It is also answered in the main post. But I will rephrase and summarize again here:
- when creating a container image that requires certain applications installed, most dockerfiles explicitly install the dependencies of said applications as well. With my tool, you only declare the package you need, and it will resolve dependencies automatically and install them for you.
- the above would work with distroless containers too, as the package manager used is outside of the produced container.
Don’t do this
If anything use a buildroot system
The best solution is to start with an Alpine container.
Distroless is not core to the idea. It’s only a nice to have. The main point is the composability, Declarative design, etc.
