Is CoreOS suitable for simple home-lab setup on local laptop metal?

Hello fedora world, thanks for the invite and all the great work you’ve shared.

I’m basically looking for something like a Silverblue-light setup and is unsure if CoreOS is suitable for that. Goal is to containerize everything and learn about clustering (?) from there. I’m also obsessed about trimming the host OS to a bare minimum which I assume CoreOS is more suited for than Silverblue. Hardware specs are retrograde and fine, i3 or i5 laptops with max 8GB RAM, preferably for a few more years.

I’ve used vagrant provisioned VMs so far but am running out of disk space and so on and would rather use pre-made (turnkey etc.) containers for servers than rolling everything from scratch and nesting them inside a VM.

Flatpaks for commonly used apps wherever that makes sense is also appealing.

I’ve read some of the excellent CoreOS documentation but would really appreciate some pointers before moving on. The only alternative I’ve come across so far are Proxmox (debian host, LXC native but podman compatible afaik) and NixOS and GNU Guix, how they differentiate from Silverblue and CoreOS ostree is beyond me atm though.

Hope that was reasonably clear, br

3 Likes

CoreOS has been more than suitable (it’s been awesome!) for my own uses – a simple, mostly hands-off, container-friendly distribution for a home-server (which handles “production” traffic). That said, CoreOS is a server OS first – the base system is aimed at running containerized workloads and not much else; I’m not even sure if integration as a Kubernetes node is part of the remit here.

You are, for the most part, not expected to interact with the system much beyond initial provisioning, and though you can extend the system with rpm-ostree, you’d be going against the grain here.

You mention Silverblue, which is more desktop-focused; there’s also Fedora IoT, which AFAICT focuses less on cloud computing and more on Edge compute-style workloads. There’s a helpful comparison here: CoreOS VS IoT editions in the rpm-ostree family

To clarify, then – to me, at least, CoreOS is wonderful if you’re looking to get containerized workloads running on a system you don’t necessarily have to worry about maintaining – just fire off the Ignition and you’re good. You might find it a tad too restrictive (with the minimal OSTree base and heavy use of SELinux) if you’re looking to experiment with the system itself, unless of course you’re interested in this sort of immutable structure.

At least, that’s my experience thus far.

4 Likes

Thanks Alex, your response is reassuring. CoreOS as a base system host remains intriguing and the config methods seems way more logical and usable than what I’m used to, even with all the available vagrant templates for easy provisioning.

I have a minimal (debian) based image prepared and in use already to host a CoreOS qemu VM as a mini learning lab. If it can be kept below 2GB all of it should fit into the main laptops RAM (on boot) which always gives a pleasant speed thrill and simple sandboxing without touching the disk much.

If all goes well the VM can be ported to the Chromebook Linux as well if needed. Neither will be used as production servers in the end anyway, only as local dev environments with some www related containers syncing to a VPS out there somewhere. In any case saving the metal exercise till later.

The coreos-installer iso ignition seems exciting :), looking forward to trying that (Customizing installation - coreos/coreos-installer)

Found a good explanation of ostree immutability details at Related Projects - ostreedev/ostree
If rpm-ostree somehow turns out to be more practical Silverblue is a fine plan B. But for now the focus is containers.

1 Like

Just some rando notes from my first almost deep dive into immutability. All very exciting and the various projects seems to be solving the same problems with clever tools that really makes you wonder why the big old kitchen sink OS install is still around.

As often mentioned in the various docs and talks: why aren’t our desktops as lean as our phones and tablets or thin clients (of the past?), why are so much effort ‘wasted’ if you will on myriads of package and config adjustments to solve more or less the same trivial user needs?

Perhaps my perception of the value proposition is exaggerated and the workhours req. to nurse non-immutable OS’s aren’t that crucial in the total time and resource budget for most users and businesses. But think about all the hours spent/wasted on tinkering and horrible update cycles and OEM blunders, change management must be a nightmare at MS for instance.

/////

Run Distrobox on Fedora Linux - Fedora Magazine led me to Portal:MicroOS - openSUSE Wiki which, at 2.3GB isn’t that micro but somehow that ended up on the disk before Silverblue. AFAIU it’s similar to Silverblue minus ostree, with btrfs instead to snapshot disaster rollbacks.

Btrfs conquered the disk immediately and I couldn’t get the usual df -h overview but anyway, the Flatpak software store was up and easy to pick up some daily driver apps from. Again, not knowing Flatpacking, hard to tell how much disk space and how many processes was initiated. Are they there after a rollback? TBC.

Their podman driven toolbox seems similar to what I’ve read about Silverblue/FCOS. Userspace also noob confusing, installing emacs in a toolbox creates configs in /home/user/.emacs, not sure where else they should be tbh, was maybe expecting something like overlayfs or chroot methods to take the traces with them when leaving the toolbox. Flatpak emacs was confused as well. I guess a proper podman env. can solve that somehow if needed.

FCOS remains a better solution (starting from almost scratch, scalable to infinity) in my beginner mindset when (config) managed in a way similar to the guix/nix pioneers who seems to be able to roll out and keep track of anything with clever declarations. Looking fw to learning how to do that the FCOS way, high hopes. Maybe that distrobox thing can keep track of the DE in a smart way and keep it separate from the precious core.

///////

Value proposition II, on the phones and tablets analogy:

Consider all the devices out there already and what ‘most people’ really need as daily driver tools. Except for gamers and VR/AR robotics stuff noone needs more CPU or RAM to do what they need to do, from now on and forever.

Consider Android without Google’s business model, when that market is finally (!?) depleted, who can streamline a Android-just-nice OS codebase that can be rolled out on any device you can get your hands on and networked to better usage.

Consider some kind of future energy crisis hitting datacenter costs all the way to the user’s budget. We’re gonna need some kind of standardized deployment that makes desktops as scalable as containers are today.

yadayada ladida almost-reddit-rant-coffee-thoughts /out

/////

Thanks again to all the FLOSS devs who made all of this fantastic tech possible and available.

I’m using FCOS on a NUC-like computer. My favourite feature is autoupdates - I don’t have to worry about package compatibility - Zincati does most of the legwork. Since all my services are containerized and backed by systemd, I barely notice the downtime (since its hosts my Home Assistant instance it increasingly becomes more important).