As we continue to push the boundaries of Linux containers, we increasingly see value in containerizing operating system-level components. It’s common for developers and administrators to turn towards containers to improve application isolation, portability, deployment scenarios, and so on. These, and plenty of other advantages, are well proven across the industry today, and the value extends to components that aren’t traditionally delivered as container images, like the Docker engine. Breaking out components like the container engine, cloud/guest agents, and storage clients, into containers isolates these stacks and allows them to move independently from the container host’s operating system.
Project News
Fedora Atomic June 6 Release
A new Fedora Atomic Host update is available via an OSTree commit:
Commit: 0ed61d7441eddf96e6a98de4f10f4675268c7888b6d2b8a405b8c21fe6c92d23
Version: 25.137
Notable updates are the kernel, systemd, bubblewrap, and runc.
6 Reasons why CRI-O is the best runtime for Kubernetes
CRI-O is a Kubernetes incubator project which is meant to provide an integration path between Open Containers Initiative (OCI) conformant runtimes and the kubelet. Specifically, it implements the Container Runtime Interface (CRI) using OCI conformant runtimes. CRI-O uses runc as its default runtime to run Kubernetes pods. For more information you can read a brief introduction here.
Let’s look at the advantages of the CRI-O project.
rpm-ostree v2017.6 released
rpm-ostree is the hybrid image/package system that provides transactional upgrades on Atomic Host. Here are some highlights from version v2017.6, including “livefs” support for adding package layers.
Future Plans for the Fedora Atomic Host Release Life Cycle
The Fedora Project ships new Fedora Server and Fedora Workstation releases at roughly six-month intervals, and maintains each release for around thirteen months. So Fedora N is supported by the community until one month after the release of Fedora N+2. Since the first Fedora Atomic Host shipped, as part of Fedora 21, the project has maintained separate ostree repositories for both of the active Fedora releases. For instance, there are currently trees available for Fedora Atomic 25 and Fedora Atomic 24.
Fedora Atomic sets out to be a particularly fast-moving branch of Fedora, with releases every two weeks and updates to key Atomic Host components such as Docker and Kubernetes, that moves more quickly than one might expect from the other releases of Fedora. Due in part to this faster pace, the Fedora Atomic Workgroup has always focused its testing and integration efforts most directly on the latest stable release, encouraging users of the older release to rebase to the newer tree as soon as possible. Releases older than the current tree are supported only on a best effort
basis, meaning that the ostree is updated, but there is no organized testing of the older releases.
Starting with either the Fedora 26 to 27 or the 27 to 28 upgrade cycle (depending on readiness), the Fedora Atomic Workgroup intends to collapse Fedora Atomic into a single version which will track the latest stable Fedora branch. When a new stable version of Fedora is released, Fedora Atomic users will automatically shift to the new version when they install updates.
Traditional OS upgrades can be disruptive and error-prone, but due to the image-based technologies that Atomic Hosts use for system components (rpm-ostree) and for applications (Linux containers), upgrading an Atomic Host between major releases is little different than installing updates within a single release. In both scenarios, the system updates are applied by running an rpm-ostree command and rebooting, with rollback to the previous state available in case something goes wrong, and applications running in containers are unaffected by the host upgrade or update.
If you’d like to get involved in the Fedora Atomic Workgroup, come talk to us in IRC in #fedora-cloud or #atomic on Freenode, or join the Atomic WG on Pagure.
Add a comment »