I don't understand how it works.
Did I guess it right that it basically processes Containerfile and instead of producing a .tar artifact (which is what container images usually are) it produces .qcow2/.ami/.raw/.iso/.vmdk file which in case of .qcow2/.raw/.vmdk can be used by a virtualization software to start up a VM with a disk mounted from that file?
Will the changes made inside a session with such a VM persist? or will they get lost (which is the default behavior with containers)?
Container's filesystem may be as narrow as a single binary file, surely a VM with such a filesystem won't be able to boot - where will it take the OS (with the kernel, drivers and other stuff) from?
Something like this is what I had desired when briefly experimenting with Fedora CoreOS and having to build layered images for ZFS support. I was new to CoreOS and was stuck right after I finished building an OCI image. Eventually I learned that the only way forward was to boot with a base image, then layer what I had built and run `rpm-ostree commit`.
I wonder if this project would've served my use case. The OCI images you build when layering FCOS images all build atop the base FCOS image. So I would expect them to be "bootable" in some sense.
On a tangential note, does anyone here remember Erlang on Xen [0]? It's a project from a decade ago, allowing you to package your code to run directly on the hypervisor without an OS. I really liked that approach and am wondering why it seems to have hit a dead end.
Keeping an eye on this. I've been wanting something like this to manage an air-gapped system. I don't want to worry about keeping on offline apt repository (or what have you) synced, I just want to boot a full new image and mount my home folder.
And we've come full circle almost.
What about the other way around? Writing my own docker(-compose)files by hand kindof stinks.
Somewhat-related, a project of mine (https://github.com/queer/peckish) allows for converting docker images to ext4 images, among other formats. A way to turn it straight to a bootable image is very cool though, I’ll have to give this a try later!
I build Ubuntu OVAs offline using debootstrap->systemd-nspawn. All you really need to do is install the kernel and initramfs packages, then mount the fs to install grub to it.
I understand this is similar to alpine-make-vm-image [0] or nixos-generators [1]
By the way, is there a way to create minimal NixOS VMs without systemd?
- [0] https://github.com/alpinelinux/alpine-make-vm-image - [1] https://github.com/nix-community/nixos-generators
https://github.com/linka-cloud/d2vm does a similar thing an I‘ve used it successfully
Nice! Same-same-but-different shameless plug: https://github.com/jrz/container-shell boot a shell into your container and mount the working/project dir
Is it something similar to d2vm(https://github.com/linka-cloud/d2vm)?
It would be nice to have my "own" Linux distro.
Really interesting. I'm guessing this would be used when you want a container experience with VM level security. Would hopefully make it easier to create bespoke VM images to do fun stuff.
I wonder as an experiment if you are able to run an instance of the parent OS via mounting /:/ and using an image that matches the parent OS…
What is a practical example of how this is useful?
Looks interesting, any Proxmox support or tests were done? I would love to see how this compares to a docker in LXC and having one for each container.
Guix did that too, right?
Excellent, now I can write docker files to run containers as VMs on FreeBSD!
That's cool! Can you use it to display react apps on the screen though?
The 'bootable container' / 'native container' space is getting really exiting, even (and especially) for desktop usecases. Atomic Fedora has had support for so called Ostree Native Containers for a while now, and that will eventually adapt `bootc` as the base layer for building and booting containers (but as of now it's not totally ready yet). VanillaOS is also working on similar things but I don't think it'll use `bootc`.
Some awesome community projects have also been born out of this space:
- https://universal-blue.org/ provides some neat Fedora images, which have one of the best Nvidia driver experiences on Linux IME, and are over all solid and dependable
- https://blue-build.org/ makes it pretty easy to build images like Universal Blue's for personal use
The best part here is really the composability; you can take a solid atomic Linux base, add whatever you like, and ship it over the air to client computers with container registries. All clients see is a diff every day, which they pull and 'apply' to be used after the next boot.