bootc has the potential to be groundbreaking (for Enterprise server Linux). A scalable and Atomic OS for servers.
Update: added related posts which solve or workaround some of the issues.
In May of 2024 Red Hat announced “Image Mode” for Red Hat Enterprise Linux. Currently Image Mode is in “Technology Preview” for RHEL. This is powered by Bootable Containers (or bootc for short). Fedora is also using this new technology, and they have great documentation.
To summarize what bootc does,
from the Fedora Documentation:
The bootc documentation summarizes bootable containers as “transactional, in-place operating system updates using OCI/Docker container images”. In other words, updates to the operating system (OS) are shipped by using container images. That implies that the Linux kernel, the bootloader, drivers, etc. are all part of the container image which renders the container image “bootable”.
These deployments are atomic, meaning they are (mostly) read-only by default.
Updates are easy, just re-build the Container Image and by default the bootc host will update (and reboot) on it’s own.
What makes bootc so exciting?
One Container Image to rule them all.
Sorry, I meant to say: One Container Image to keep every server up to date, automatically.
Every server automatically checks for a new container image. When there’s a new image, the server automatically updates. If the update or reboot fails, no problem. It will “auto-heal”. (there’s a buzz word I haven’t heard in a while!)
There is also no chance of a different package version being installed during a rolling update of many servers (when external repositories are not in your control).
If you need more than one image (if you have many different workloads on your servers then don’t put everything into one image!), it’s pretty simple to have a single “base image” and many specialized images built from that.
You can also leverage your existing Container Image build tools/processes, and knowledge around building Container Images. Something else that can help is using a heredoc in Containerfile (Dockerfile).
What could be better?
- Updates require a reboot.. for any update, any package install.
- There is still possibility for configuration drift in /etc
- Initial install can be difficult.
This can be solved by bootstrapping bootc from Fedora CoreOS. - Can’t easily add extra (non-root) disk (via the Dockerfile/Containerfile).
Also solved by bootstrapping bootc from Fedora CoreOS. - Some packages can’t be installed into a Container.
Workarounds: Tips to install RPM packages in bootc image builds - SELinux issues when installing packages.
- No release notes or changelog to see what packages change.
This can be solved by creating and comparing SBOM of bootc image. - Day 2 configuration changes are somewhat painful. Redeploying the entire OS isn’t great if you want to be truly immutable.
- Ansible doesn’t detect a bootc server any different from a normal RHEL or Fedora installation. But trying to install a package on a bootc server will obviously fail the Ansible Playbook. This makes re-using Ansible Roles difficult.
Can be solved by changing how Ansible detects a bootc based server. - Simple things like user management are not simple considering issues with drift. This means using Ansible for User Management doesn’t really make sense anymore.
- Advanced automatic update mechanism not included, like rolling updates of a 5 node cluster.
Conclusion
I think bootc has the potential for amazing things in 2025 (and beyond). An Atomic server OS that scales. Even with the above somewhat long list of needed improvements, I’m still very excited. Is it too early to start using Bootable Containers in production? I don’t think so.