After creating a lightweight VM to run my containers on Fedora CoreOS, it dawned on me that I probably could have just used the base Fedora bootc image instead.
What reasons are there for using CoreOS over the base Fedora bootc image? Ignition and Afterburn are useful, but the tasks handled by Ignition can also be done by modifying the base Fedora bootc image and creating and deploying your storage and image with Podman.
Is it simply a matter of ease of deployment? Is it better to be more future proof to go with fedora-bootc?
If I understand correctly, CoreOS will not be replaced by bootc but rather will adopt bootc to replace the currently used rpm-ostree in the future. I’m not clear on whether the switch will be completely seamless but you certainly won’t have to throw your existing config out the window.
The fundamental idea of CoreOS is having an opinionated base system with everything you need for deploying containerized applications in a security-hardened environment. The CoreOS team will take care of patching and maintaining that system for you and you are not supposed to have to make any changes to it (like installing packages) except for declaratively changing configuration files and adding your services.
I think it is quite valuable to have your storage configuration (including multiple physical storage devices, RAID setups, disk encryption, etc.) declared right next to the rest of your configs.
Much more important to me is the automatic updating though. When packaging your configurations and services as part of the bootable container image, you’ll have to maintain your own pipeline to regularly build and pull new images when the base image changes.
If CoreOS is currently fitting your use-case, I don’t really see a reason to abandon it
I see your point. The only thing I’d add is that, as far as I can tell, Zincati really only works properly if you’re not layering any packages or if all your layered content is managed through rpm-ostree.
I’d rather not go down the road of layering packages with rpm-ostree since bootc is the future. Instead, I build my own image and include a few essentials I need, like the example below:
This setup works well. To be fair, the Universal Blue folks include much of this in uCore, but I don’t need all the extras they package. Some of these tools are non-negotiable for me. Sure, I could drop zsh, starship, or atuin, but since this runs in a VM with qemu-guest-agent and virtio disks, I really can’t do without those.
Maybe I missed something, but is there a CoreOS image out there built for VMs that already includes the guest agent and additional Cockpit components? I don’t recall seeing one. Not that it would matter much, I’d still need to add tailscale manually afterward.
It occurred to me after deploying CoreOS that my minimal package subset probably could’ve been done using fedora-bootc instead and then wondered if there is any need in the future if I built another VM.
Well, I’d say you are not investing much work that will be lost when using rpm-ostree for now. Once CoreOS with bootc is available, you can probably migrate rather quickly if all you have to do is taking care of the layered packages. That way you will always benefit from the automatic updates and end up using bootc eventually anyways.
For at least some of your required packages it might be sufficient to run them inside a (privileged) container instead of installing them through the package manager. Someone apparently even did that for qemu-guest-agent.
However, there are nuances that likely depend on your specific use case or preferences. There was also a brief chat on this topic in the CoreOS Matrix room, and if you are interested, I can provide a summary here.
Some are, some aren’t, some are easier and some aren’t in both directions.
It’s much more than that. For example, Fedora CoreOS (FCOS) uses streams, is fully automated in terms of updates and upgrades to major versions, and is extensively tested.
FCOS is already based on and built using bootc images.
bootc also has a basic capability to automatically update the deployed image.
Technically this is not necessary and you can easily build and upgrade/switch to your local images. This is especially useful when images are large and/or for development and testing purposes.
Package layering does not break Zincati, but a derived build from FCOS will. However, it is likely that this will be resolved in the future.
As far as I know, there isn’t.
The above basically summarizes the brief conversation on the topic in the FCOS Matrix room.
Thanks for all that, especially the info on possibly having zincati work with a derived image. Thats how I currently make my image on github. That being said, it’s not THAT hard to automate bootc upgrade with with a systemd timer or something and then reboot but I appreciate all the work the team is doing to make FCOS and fedora-bootc easier to use.
There is a long-term plan for this (supporting Zincati with custom OCI images), but some tooling need to be built around it. And time, unfortunately, is a limited resource.
While Zincati is nice, the value of FCOS updates is not strictly limited to it. You will benefit from all the care the FCOS team puts into the migration code and barrier releases if you update frequently enough (at least once a week is a safe bet) without Zincati.
Reading this, I’m not entirely sure if you’re aware of bootc-fetch-apply-updates.service, but in case you’re not, here it is:
I also highly recommend reading other sections of the bootc manual, as it is included in the FCOS images. However, keep in mind that its functionality may be limited:
Here’s another useful piece of information:
Like the bootc manual, I highly recommend reading the Fedora/CentOS bootc documentation if you haven’t already:
Thanks for that info on the update service. I’ll take a look. It PAYS to read the documentation I had decided to make an effort to move my containers to FCOS but I hadn’t read the docs through. I’ll definitely read through the links you sent. Thank you!
I had decided to make an effort to move my containers to FCOS but I hadn’t read the docs through. I’ll definitely read through the links you sent. Thank you!