Red Hat Enterprise Linux Atomic Host: Updates Made Easy

Earlier in March we announced the general availability of Red Hat Enterprise Linux 7 Atomic Host, a small footprint, container host based on Red Hat Enterprise Linux 7. It provides a stable host platform, optimized for running application containers, and brings a number of application software packaging and deployment benefits to customers. In my previous container blog I gave the top seven reasons to deploy Red Hat Enterprise Linux 7 Atomic Host. One reason was the ability to do atomic updates and rollbacks. In this blog I provide an in-depth look into atomic updating and how it differs from a yum update. And, speaking of atomic updates

… it just so happens that our first atomic update was made available yesterday.

Yum Updates

Red Hat Enterprise Linux is made up of a collection of RPMs that use the Red Hat package manager yum to: query for information about available packages, fetch packages (from repositories), install / uninstall packages, and (more generally) update the entire system with the latest available versions of packages. Yum performs automatic dependency resolution on packages you are updating, installing, or removing, and is thus able to automatically determine, fetch, and install all available dependent packages. However, at any given time, each of your systems can have versions of packages that are slightly outdated, depending on when you last updated your system. This by itself might or might not be an issue.

The reality is that environments are often times not mirror images of each other. As you move from development to testing of your software application, your testing environment might not match the development system. We call this an inconsistent environment, and it can yield inconsistent testing results. The same is true when moving from test to production. In addition, should you choose to avoid the frustrations associated with having inconsistent environments between “dev”,“test”, and “prod”, it can take awhile to procure physical dev and test systems and to then customize them exactly to match the operating system version and patch level that you have on your production system.

Atomic Updates

Red Hat Enterprise Linux Atomic Host helps to solve the aforementioned problem through its ability to support a container-based application infrastructure. With containers, the software application is bundled along with its runtime dependencies into single package using the docker format. In this way, as you move your container-based application from development to testing and into production, the container, along with its own unique runtime dependencies, are run on compatible, certified hosts (i.e. there’s no need to worry about the host as each container has everything it needs to ensure the associated application runs as desired). Your containers can run on both Red Hat Enterprise Linux 7 and Red Hat Enterprise Linux 7 Atomic Host.

With respect to updating the host - Red Hat Enterprise Linux 7 Atomic Host features a new update system based on rpm-ostree. Rpm-ostree is an open source tool used  to manage bootable, immutable, versioned file system trees made of RPM content. RPMs are composed on a server into an OSTree repository and client systems can replicate these in an image-like fashion. The resulting atomic trees make incremental updating of the host OS much simpler by supporting the ability to check for, download, and deploy updated versions in a single step. Red Hat Enterprise Linux Atomic Host provides aggregated content or “images” that are “atomic” or indivisible.

Also, unlike traditional operating system update mechanisms, Red Hat Enterprise Linux 7 Atomic Host automatically keeps the previous version of the host OS “on hand”, supporting the ability to easily rollback to an earlier state. When updating, Atomic Host does not change the running system, instead, it creates a new operating system root to place the atomic tree upgrade and sets the default to boot into the new root. By default, two available roots are kept. This simplified upgrade and rollback capability allows our customers to focus on running applications that bring business value.

Included below is an example of the typical upgrade workflow for Red Hat Enterprise Linux Atomic Host. Note that before performing an atomic upgrade, you must have first downloaded and installed Red Hat Enterprise Linux 7 Atomic Host. Then, to enable software updates, you must register your Red Hat Enterprise Linux 7 Atomic Host installation using subscription manager.

Step 1: Register your Red Hat Atomic Host installation using subscription manager.

# subscription-manager register --username=<username> --auto-attach

Password:

The system has been registered with ID: b32edba2-82c0-451f-a248-90f0f49c43a7

Installed Product Current Status:

Product Name: Red Hat Enterprise Linux Server

Status: Subscribed

Product Name: Red Hat Enterprise Linux Atomic Host

Status: Subscribed

Step 2: View current status of installed Red Hat Enterprise Linux 7 Atomic Host.

# atomic host status

TIMESTAMP (UTC) VERSION ID OSNAME REFSPEC

* 2015-02-05 14:52:09 7.1.0 9d04d17969 rhel-atomic-host rhel-atomic-host:rhel-atomic-host/7/x86_64/standard

Step 3: Upgrade to the new/latest atomic ostree.

# atomic host upgrade

At this point the upgrade is complete but the host is still running the current installation (...unlike traditional Red Hat Enterprise Linux - the running system is not affected by an upgrade). Two versions of Red Hat Enterprise Linux Atomic Host are available on the system after the initial upgrade. One is the currently running version. The other is either a new version recently installed from an upgrade or the version that was in place prior to the last upgrade.

Step 4: Reboot into the upgrade.

# systemctl reboot

Step 5: If you have issues - you have the option to rollback to the prior running state.

# atomic host rollback

# systemctl reboot

For acess to additional documentation, visit the Red Hat Customer Portal: https://access.redhat.com/articles/rhel-atomic-documentation

Update Cadence

We are planning to provide an atomic update that stays consistent with the Red Hat Enterprise Linux kernel and user space erratas we make available.  This means that the atomic update will stay in sync with the asynchronous kernel errata.

Questions about atomic updating or how atomic updating differs from (the more traditional) yum update approach?  Please use the comments section (below) to inquire further and/or to share your feedback and ideas.