Along my own journey of demystification I made a few toy container image registries over the years that generated and served container images from nothing but the URL itself:
https://ko.kontain.me builds a go application on demand and serves it atop a minimal base image
https://apko.kontain.me builds a base image containing packages listed in the URL, again on demand.
The latest addition, https://git.kontain.me serves an image with the specified git repo already checked out in the image.
None of these should be used for anything serious but they were fun to make and play with. :)
random.kontain.me has been uncharacteristically useful in debugging image caching scenarios.
I have yet to receive any commercial interest in any of these tools :)
Building every time takes a lot of time. Both on download and execution time.
Also when building an image you may need to have access to resources that are unavailable where you actually want to run the image. So I see definitely reason for both to exist.
Or am I misunderstanding your point?
this sounds interesting; for e.g., was wondering the other day if we could build images without actually pulling base images.. everytime we compile, we copy artifact(s) onto a multi-hundred MB base image which definitely doesn't need to be pulled everytime.
(I am a maintainer)
We already have image builders for stuff like Talos Linux and Incus OS. This is not out of the realm of possibility.
What are the limitations of `docker build`?
I haven’t tried lately, but I think running a build still requires running a docker engine. Buildx has builders that run as containers.
Is "build" being used here in the sense of assembling pre-existing layers into an image? What would be the purpose of that?
In a more real scenario, you can e.g., turn pip wheels into layers without actually using docker's RUN command. All it takes is to massage the data from one archive format into another, programmatically. This unlocks lots of potential (e.g., it becomes embarrassingly parallel to build a container image comprised of pip wheels). Combine that with a good layer caching strategy and a registry that takes advantage of it, and you can have near-instant container builds for arbitrary sets of wheels.