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!
And uses SOAP for identity and authorization.
Fully in-browser container builds
11–20 of 29 posts
Re: Fully in-browser container builds
#12GAME CHANGER
Re: Fully in-browser container builds
#13I 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.
Re: Fully in-browser container builds
#14> 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)
Re: Fully in-browser container builds
#15I don't understand what this does. How can it "build" anything without a VM capable of running actual code?
Is "build" being used here in the sense of assembling pre-existing layers into an image? What would be the purpose of that?
Re: Fully in-browser container builds
#16> 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.
There are many ways to achieve this. If you are just copying artifacts, and not using RUN, then there is in principle no need to download the base image at all. Feel free to message me if you'd like to chat (email is in my profile).
Re: Fully in-browser container builds
#17I 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.m…
I sometimes wonder why there aren't more bespoke container tools (like yours). Would people be willing to pay for stuff like what you have built, if someone took the time to "productionize" it? Or is there no market?
Re: Fully in-browser container builds
#18I 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.m…
I sometimes wonder why there aren't more bespoke container tools (like yours). Would people be willing to pay for stuff like what you have built, if someone took the time to "productionize" it? Or is there no market?
AFAIK people only begrudgingly pay for Docker and it does way waaay more.
I have yet to receive any commercial interest in any of these tools :)
Re: Fully in-browser container builds
#19I don't understand what this does. How can it "build" anything without a VM capable of running actual code? Is "build" being used here in the sense of assembling pre-existing layers into an image? What would be the purpose of that?
The idea is that, in many cases, you can create a layer "by hand" without running actual Linux programs. Layers don't need to be pre-existing, the only requirement is that they can be built programmatically (inside the browser, in this case). The demo actually does that: it "manually" creates a layer from the user-specified entrypoint script, then creates an image from the pre-existing base image's layers and the new entrypoint layer.
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 pip dependencies.
Re: Fully in-browser container builds
#20[dead]