Project Atomic is now sunset

The Atomic Host platform is now replaced by CoreOS. Users of Atomic Host are encouraged to join the CoreOS community on the Fedora CoreOS communication channels.

The documentation contained below and throughout this site has been retained for historical purposes, but can no longer be guaranteed to be accurate.

Project News

Fedora 27 Atomic Host February 16th Release

In this week’s release of Fedora Atomic Host we have a new kernel, Atomic CLI, and runc.

A new Fedora Atomic Host update is available via an OSTree update:

Version: 27.81

  • Commit(x86_64): b25bde0109441817f912ece57ca1fc39efc60e6cef4a7a23ad9de51b1f36b742
  • Commit(aarch64): bb5bc5afbf27333a70c1f3bf8d0117baa45e862e0440be5c779cd5f0bb35aab4
  • Commit(ppc64le): e484af3c5a5c88c0de486eee195dff4c6c7ef41d07c41b5d356305db237066d7

We are releasing images from multiple architectures but please note that x86_64 architecture is the only one that undergoes automated testing at this time.

Existing systems can be upgraded in place via e.g. atomic host upgrade or atomic host deploy.

Read More »

An Introduction to Fedora Atomic Workstation

For the last few Fedora releases, the Workstation WG has been working on combining the best of the Project Atomic pattern with the Fedora Workstation Edition into a deliverable dubbed “Fedora Atomic Workstation”. In Fedora 27, we have reached a point where we feel comfortable inviting other developers and enthusiasts to try it out and even make it their daily driver.

Read on to discover what Fedora Atomic Workstation is, what its benefits are, and how you can get started today!

Note: this blog post is based on a talk I gave at DevConf.cz 2018. Head over to YouTube if you’d prefer listening to it.

Read More »

Fedora 27 Atomic Host February 2nd Release

In this week’s release of Fedora Atomic Host we have a new kernel, ostree/rpm-ostree, glibc, and cloud-utils-growpart (fixes for aarch64 partition resize issues).

The new Fedora Atomic Host update is available via an OSTree update:

Version: 27.72

  • Commit(x86_64): 39848372585a65dc63fb3052f997139b8b30d6b55ce378337db3664177489d28
  • Commit(aarch64): 8048d384f231f90a7479cf94bfe94053970fb9a0f196ba4485d779696db81fa1
  • Commit(ppc64le): 3fce2908406e41e2ffe533908e840f44311576befe7e49396d1894407341aef9

We are releasing images from multiple architectures but please note that x86_64 architecture is the only one that undergoes automated testing at this time.

Existing systems can be upgraded in place via e.g. atomic host upgrade or atomic host deploy.

Read More »

Firewalld in Atomic Host

TL;DR

Fedora Atomic Host (and derivatives) will now include the firewalld package in the base OSTree that is tested, delivered, and released every two weeks. Existing users should observe no change as it won’t be enabled by default.

Firewalld in Atomic Host

In the past we have had requests to have firewalld in Atomic Host to enable a better interface into firewall management for administrators and management software. It turns out that if you have lots of rules to manage, or even multiple pieces of software trying to manage different sets of rules on a single system, then iptables becomes a limitation pretty quickly.

Atomic Host users do have the ability to package layer firewalld, but live changes to the host are currently experimental. Since rebooting during system provisioning in certain environments is not desirable, and firewalld is relatively small, the Fedora Atomic Working Group decided to include firewalld in the base OSTree.

In order to not affect existing users the firewalld service will be disabled by default. Existing users should observe no change in behavior. Users who want to use firewalld can enable/start the service and start using it immediately.

Read More »

Using OCI Image Registries with Buildah

Buildah

Using Buildah with container registries

Prerequisite: Buildah version 0.9 or greater.

First some terminology. In the container image space, Docker popularized two terms:

  • Container image registry
  • Container image repository

The container image registry, or registry, is a shared data store for pushing and pulling container images. It has a well-known API for such requests. Docker Hub is an example of a public registry. Various vendors and developers store their images on Docker Hub. Most organizations I’ve dealt with don’t wish to pull images from a public registry for reasons such as security or network bandwidth usage. Instead they would prefer to use a local private registry.

Read More »