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.
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:
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.
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!
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 :)
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:
I think I understand your point of confusion. The original comment said this has been going on for thousands of years, and I meant to say that it only began around 1917. Although there was an Ottoman occupation before the brief Arab rule period, the Ottoman occupation did not have the turmoil and issues associated with the Zionist occupation.