I love seeing folks learn that container images are just fancy tar files and JSON and are therefore buildable by normal tools.
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.
Interesting... but also the "power" from container is precisely that the description itself, i.e. the Dockerfile, is sufficient. So I'm not sure what the main advantage of either providing the image itself via a registry or providing just the Dockerfile with the base image to another registry then adding steps add.
An image is immutable, many Dockerfiles are not idempotent. Running them multiple times at different times can lead to different results easily.
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?
> we brought down image creation time to mere seconds, even for images that were multiple GiB in size
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.
You absolutely can just build things and put them on base images without building or pulling the base image at any point. This is a central feature of ko, a simple container build tool for most Go applications: https://ko.build
(I am a maintainer)
You can, by using FUSE and lazy pulling files as they are opened. I'm working on doing this, myself.
One of the neat things about something like this is that you could, in theory, do OS builds (think stuff like bootable containers) where you can, deterministically, configure an operating system to boot into all within the confines of your web browser.
We already have image builders for stuff like Talos Linux and Incus OS. This is not out of the realm of possibility.
> and we sometimes resign ourselves to the limitations of docker build and friends
What are the limitations of `docker build`?
Creating multi arch builds for starters. Maybe creating image from just composing layers instead of “running” a Dockerfile? The first I find cumbersome and is easily overcome by using buildx.
I haven’t tried lately, but I think running a build still requires running a docker engine. Buildx has builders that run as containers.
GAME CHANGER
I joked once that the future was dockerizing every single react component and running them in a wasm port of k8s... I hope that premonition isn't coming true!
I can't imagine this happening in reality (i.e. people wanting to do this for normal production applications), but after reading your comment I must admit I am very tempted to try it for purely esoteric reasons.
I love seeing folks learn that container images are just fancy tar files and JSON and are therefore buildable by normal tools.
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.
Interesting... but also the "power" from container is precisely that the description itself, i.e. the Dockerfile, is sufficient. So I'm not sure what the main advantage of either providing the image itself via a registry or providing just the Dockerfile with the base image to another registry then adding steps add.
An image is immutable, many Dockerfiles are not idempotent. Running them multiple times at different times can lead to different results easily.
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?
> we brought down image creation time to mere seconds, even for images that were multiple GiB in size
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.
You absolutely can just build things and put them on base images without building or pulling the base image at any point. This is a central feature of ko, a simple container build tool for most Go applications: https://ko.build
(I am a maintainer)
You can, by using FUSE and lazy pulling files as they are opened. I'm working on doing this, myself.
One of the neat things about something like this is that you could, in theory, do OS builds (think stuff like bootable containers) where you can, deterministically, configure an operating system to boot into all within the confines of your web browser.
We already have image builders for stuff like Talos Linux and Incus OS. This is not out of the realm of possibility.
> and we sometimes resign ourselves to the limitations of docker build and friends
What are the limitations of `docker build`?
Creating multi arch builds for starters. Maybe creating image from just composing layers instead of “running” a Dockerfile? The first I find cumbersome and is easily overcome by using buildx.
I haven’t tried lately, but I think running a build still requires running a docker engine. Buildx has builders that run as containers.
GAME CHANGER
I joked once that the future was dockerizing every single react component and running them in a wasm port of k8s... I hope that premonition isn't coming true!
I can't imagine this happening in reality (i.e. people wanting to do this for normal production applications), but after reading your comment I must admit I am very tempted to try it for purely esoteric reasons.
And uses SOAP for identity and authorization.