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.

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 Groupdecided 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.

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.