[HN Gopher] Show HN: Convert your Containerfile to a bootable OS
___________________________________________________________________
Show HN: Convert your Containerfile to a bootable OS
Author : twelvenmonkeys
Score : 95 points
Date : 2024-05-07 17:50 UTC (5 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| falcor84 wrote:
| 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.
|
| [0] https://github.com/cloudozer/ling
| bobek wrote:
| It is not the same (as it uses Linux kernel) but Nerves project
| is an interesting way of using BEAM (Erlang VM) for "embedded"
| applications.
| mikef25 wrote:
| https://github.com/linka-cloud/d2vm does a similar thing an I've
| used it successfully
| notamy wrote:
| 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!
| nubinetwork wrote:
| What about the other way around? Writing my own
| docker(-compose)files by hand kindof stinks.
| MenhirMike wrote:
| So, a bit like docker container commit but actually good?
| koito17 wrote:
| 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.
| jcastro wrote:
| uCore does this if you wanna check it out:
| https://github.com/ublue-os/ucore
| monstajoe wrote:
| That's cool! Can you use it to display react apps on the screen
| though?
| OJFord wrote:
| If that's what your entrypoint sets up, yeah?
| allyant wrote:
| 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...
| FireInsight wrote:
| 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.
| themgt wrote:
| There's also Elemental which is SUSE-oriented but distro
| agnostic https://github.com/rancher/elemental-toolkit
|
| I've been hoping NixOS moves in this direction over time, the
| distribution/rollout aspect seems under-baked currently.
| hhh wrote:
| What's the best way to start with Elemental today? I haven't
| been able to grasp a start point, unlike RKE/Rancher which is
| pretty easy to onboard.
| themgt wrote:
| It depends what you're trying to do, but I was essentially
| following this guide: https://rancher.github.io/elemental-
| toolkit/docs/examples/em... updated to
| ghcr.io/rancher/elemental-toolkit/elemental-cli:v1.3.0 /
| registry.suse.com/suse/sle-micro-rancher/5.4
|
| The whole project is in major flux now though, with v1.3 ->
| v2.1 being pre-release and docs haven't been updated, so
| I'm waiting for dust to settle before picking it back up.
| But basically `docker build` -> `elemental build-disk` ->
| qcow2/iso -> deploy / `elemental upgrade` update via OCI
| registry, or deploy vanilla image and then just update that
| via registry.
| ranger_danger wrote:
| One of my biggest complaints with distros has been the lack of
| documentation on how to actually build the distro itself, not
| just an ISO but like build all the packages from source as
| well. Like as if you were following an LFS book. I have seen
| VERY few distros that provide this.
|
| Do you think this helps that at all?
| jbverschoor wrote:
| 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
| FireInsight wrote:
| That seems more like Distrobox to me(?) https://distrobox.it/
| anthk wrote:
| Guix did that too, right?
| satertek wrote:
| 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.
| cogman10 wrote:
| 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.
___________________________________________________________________
(page generated 2024-05-07 23:00 UTC)