Rancher/LinuxKit style systems


#1

This is a random discussion - does anyone think it would be useful if the operating system itself was made out of multiple containers, like e.g. Rancher and LinuxKit do?

I think about this on and off. It also came up with the idea that was floated a while ago that e.g. a workstation like Silverblue could actually just be a container on top of e.g. Fedora CoreOS.

The thing I struggle with is it’s a fairly fundamental departure from how “classic” systems work; we simply could not make it transparent. For example, you would now need to configure TLS trust roots in two places.
In many cases it seems to me, you end up wanting to “bind together” these different containers and ship them as a single update - while in theory, sure, someone could just update the chrony/time-sync container separately, when would you really ever want that?

Are there any people who use Rancher or LinuxKit-derived systems who have found the technology useful?

So far it’s been a relatively nice alignment point for merging Container Linux and Atomic Host in that both are basically “image-based derivatives” of the upstream distributions (Gentoo and Fedora) respectively - in my view they’re “spins” but something like LinuxKit is a far more fundamental departure.


#2

Not answering your question directly since I’ve never used Rancher or LinuxKit style stystems, but I’ve often thought about a “host contexts” idea. Where you essentially have different overlays of the host filesystem you can play around with. This isn’t necessarily for Fedora CoreOS (maybe more for silverblue). Here is the idea:

# ls /usr/bin/hostcontext
# alias hc=hostcontext
# hc enter
Entering 'default' host context
hc-default# dnf install htop
hc-default# exit
# hc new foo
# hc enter foo
Entering 'foo' host context
hc-default# dnf install emacs
hc-default# exit
# hc list
default
foo
# hc delete foo

The host contexts would build on top of the host filesystem and attempt to be upgraded when the host updates, OR you can disconnect them from the host and make them not upgrade by default. They can probably be implemented via containers or some snazzy chrooting.

This host contexts idea could allow us to provide a “default” host context that has some stuff in it and would allow us to make the base smaller maybe??


#3

That’s what I thought was the end game for Fedora Atomic Workstation / Silverblue - a minimal core (kernel plus container hosting plus git) with everything else (display manager, desktop apps, services) running in containers.


#4

When we looked at this before, “desktop as container” never made much sense. There is a big interface between the desktop and the plumbing layers. Not a natural place to put a container boundary.


#5

My desktop dream, similar to what @znmeb said, was to have a minimal system where I can add the things I want in a config file (see @dustymabe’s comment) or even via GUI and then I’d just have my perfect desktop environment with exactly the file explorer, window manager, and other stuff I wanted without all the bloat.

One can dream.


#6

I’m not saying that something like that can’t be engineered.

Just that it would probably not look much like a container.


#7

Don’t get me wrong - the GNOME 3 desktop is my interface of choice. My second choice would be a ChromeBook but with Firefox as the browser. :wink: