The Fedora CoreOS team is excited to announce the first preview release of Fedora CoreOS, a new Fedora edition built specifically for running containerized workloads securely and at scale. It’s the successor to both Fedora Atomic Host and CoreOS Container Linux. Fedora CoreOS combines the provisioning tools, automatic update model, and philosophy of Container Linux with the packaging technology, OCI support, and SELinux security of Atomic Host.
Read on for more details about this exciting new release.
Why Fedora CoreOS?
Containers allow workloads to be reproducibly deployed to production and automatically scaled to meet demand. The isolation provided by a container means that the host OS can be small. It only needs a Linux kernel, systemd, a container runtime, and a few additional services such as an SSH server.
While containers can be run on a full-sized server OS, an operating system built specifically for containers can provide functionality that a general purpose OS cannot. Since the required software is minimal and uniform, the entire OS can be deployed as a unit with little customization. And, since containers are deployed across multiple nodes for redundancy, the OS can update itself automatically and then reboot without interrupting workloads.
Fedora CoreOS is built to be the secure and reliable host for your compute clusters. It’s designed specifically for running containerized workloads without regular maintenance, automatically updating itself with the latest OS improvements, bug fixes, and security updates. It provisions itself with Ignition, runs containers with Podman and Moby, and updates itself atomically and automatically with rpm-ostree.
Provisioning immutable infrastructure
Whether you run in the cloud, virtualized, or on bare metal, a Fedora CoreOS machine always begins from the same place: a generic OS image. Then, during the first boot, Fedora CoreOS uses Ignition to provision the system. Ignition reads an Ignition config from cloud user data or a remote URL, and uses it to create disk partitions and file systems, users, files and systemd units.
To provision a machine:
- Write a Fedora CoreOS Config (FCC), a YAML document that specifies the desired configuration of a machine. FCCs support all Ignition functionality, and also provide additional syntax (“sugar”) that makes it easier to specify typical configuration changes.
- Use the Fedora CoreOS Config Transpiler to validate your FCC and convert it to an Ignition config.
- Launch a Fedora CoreOS machine and pass it the Ignition config. If the machine boots successfully, provisioning has completed without errors.
Fedora CoreOS is designed to be managed as immutable infrastructure. After a machine is provisioned, you should not modify /etc or otherwise reconfigure the machine. Instead, modify the FCC and use it to provision a replacement machine.
This is similar to how you’d manage a container: container images are not updated in place, but rebuilt from scratch and redeployed. This approach makes it easy to scale out when load increases. Simply use the same Ignition config to launch additional machines.
Automatic updates
By default, Fedora CoreOS automatically downloads new OS releases, atomically installs them, and reboots into them. Releases roll out gradually over time. We can even stop a rollout if we discover a problem in a new release. Upgrades between Fedora releases are treated as any other update, and are automatically applied without user intervention.
The Linux ecosystem evolves quickly, and software updates can bring undesired behavior changes. However, for automatic updates to be trustworthy, they cannot break existing machines. To avoid this, Fedora CoreOS takes a two-pronged approach. First, we automatically test each change to the OS. However, automatic testing can’t catch all regressions, so Fedora CoreOS also ships multiple independent release streams:
- The testing stream is a regular snapshot of the current Fedora release, plus updates.
- After a testing release has been available for two weeks, it is sent to the stable stream. Bugs discovered in testing will be fixed before a release is sent to stable.
- The next stream is a regular snapshot of the upcoming Fedora release, allowing additional time for testing larger changes.
All three streams receive security updates and critical bugfixes, and are intended to be safe for production use. Most machines should run the stable stream, since that receives the most testing. However, users should run a few percent of their nodes on the next and testing streams, and report problems to the issue tracker. This helps ensure that bugs that only affect certain workloads or certain hardware are fixed before they reach stable.
Telemetry
To help direct our development efforts, Fedora CoreOS will perform some telemetry by default. A service called fedora-coreos-pinger will periodically collect non-identifying information about the machine, such as the OS version, cloud platform, and instance type, and report it to servers controlled by the Fedora project.
No unique identifiers will be reported or collected, and the data will only be used in aggregate to answer questions about how Fedora CoreOS is being used. We will prominently document that this collection is occurring and how to disable it. We will also tell you how to help the project by reporting additional detail, including information that might identify the machine.
Current status of Fedora CoreOS
Fedora CoreOS is still under active development, and some planned functionality is not available in the first preview release:
- Only the testing stream currently exists; the next and stable streams are not yet available.
- Several cloud and virtualization platforms are not yet available. Only x86_64 is currently supported.
- Booting a live Fedora CoreOS system via network (PXE) or CD is not yet supported.
- We are actively discussing plans for closer integration with Kubernetes distributions, including OKD.
- Fedora CoreOS Config Transpiler will gain more sugar over time.
- Telemetry is not yet active.
- Documentation is still under development.
While Fedora CoreOS is intended for production use, preview releases should not be used in production. Fedora CoreOS may change in incompatible ways during the preview period. There is no guarantee that a preview release will successfully update to a later preview release, or to a stable release.
The future
We expect the preview period to continue for about six months. At the end of the preview, we will declare Fedora CoreOS stable and encourage its use in production.
CoreOS Container Linux will be maintained until about six months after Fedora CoreOS is declared stable. We’ll announce the exact timing later this year. During the preview period, we’ll publish tools and documentation to help Container Linux users migrate to Fedora CoreOS.
Fedora Atomic Host will be maintained until the end of life of Fedora 29, expected in late November. Before then, Fedora Atomic Host users should migrate to Fedora CoreOS.
Getting involved in Fedora CoreOS
To try out the new release, head over to the download page to get OS images or cloud image IDs. Then use the quick start guide to get a machine running quickly. Finally, get involved! You can report bugs and missing features to the issue tracker. You can also discuss Fedora CoreOS in Fedora Discourse, the development mailing list, or in #fedora-coreos on Freenode.
Welcome to Fedora CoreOS, and let us know what you think!
drakkai
What are the main differences between Fedora CoreOS and Silverblue? Both are suppose to use rpm-ostree and are focused on containers. Is the difference only that Silverblue is for desktops and CoreOS is made for OKD/K8s? Or is there something more? (I omit the installation method, Ignition vs Anaconda).
Is this the same combination as in the case with Fedora Server and Fedora Workstation, but in the world of containers?
Paul W. Frields
@drakkai: The use case split is definitely part of it. Fedora CoreOS is a minimal OS designed for container use, OKD, Kubernetes, etc. Silverblue is designed to be a fully-featured, graphical workstation for developers. Fedora Server is a little different in that it wasn’t specifically designed to be minimal.
Colin Walters
Yes, the desktop vs server is the biggest distinction.
However I’m working slowly in the background on having Fedora Silverblue actually derive from Fedora CoreOS, which indeed means having a “dd to disk” install path and support for Ignition as opposed to Anaconda. And sharing some of the build infrastructure (and branching model noted above), and perhaps most importantly to users, doing automatic updates by default and staged rollouts via Cincinnati/Zincati etc.
See e.g.
https://github.com/coreos/coreos-assembler/pull/639
https://github.com/cgwalters/fedora-silverblue-config/tree/f30-coreos-based
Ivan Boyko
Great news!
We are keen users of CoreOs, and happy to see it continuing to live under Fedora brand.
Andropause
Telemetry. “nuff said
Sivakumar
This is really a great news. I am checking with test stream at my development environment.
Eric L.
Will there be documentation on how to migrate from Fedora Atomic to Fedora CoreOS?
PF Renard
Will aarch64 supported in the future ?
Benjamin Gilbert
That’s the goal! See https://github.com/coreos/fedora-coreos-tracker/issues/13.
Jonathan Lebon
Yes, along with ppc64le and possibly s390x at some point. Check out the related tracker issues for those: https://github.com/coreos/fedora-coreos-tracker/issues/13 and https://github.com/coreos/fedora-coreos-tracker/issues/78. A lot of the multi-arch enablement is happening in coreos-assembler if you’d like to subscribe!
Stuart D Gathman
Good writeup. I feel like I understand the roadmap and purpose after reading it.