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.

  1. Still confused somewhat about ‘ostree’ .. the name implies it has something to do with the OS file system tree. Below is my current ‘understanding’:

    A container has a relatively small foot print of about 150 MB which is the ‘overhead’ of the virtualized container.

    -bash-4.2# docker save rhel7/latest > /var/tmp/rhel7-copy.tar
    -bash-4.2# ls -l /var/tmp/rhel7-copy.tar
    -rw-r–r–. 1 root root 154297344 Jan 26 03:47 /var/tmp/rhel7-copy.tar

    The OSTree is a virtualized equivalent of the physical OS file system tree made available to each container.

    Docker environment simulates the underlying OS to the container as this OSTree structure.

    Add an application, for example httpd, into the container, results in adding the installation files, ‘patch’, that the real OS tree would accumulate, but applied against this virtual copy of the OS Tree inside the container. The container grows by the size of space needed for this ‘patch’ of files to be added.

    One or more RPM packages, when installed, updates the file tree, appends a ‘patch’ of files. These are the various cached intermediary pieces built along the way.

    The container maintains the ‘patch’ of files needed to add the new application functionality to the current OS tree of files.

    A container is essentially the docker overhead of virtualization plus a ‘patch of files’ to the current OS tree representing the application.

    Is this a fair assessment of the docker container world?

    1. OSTree as productized in RHEL Atomic Host is independent of the content inside the container.

      OSTree is a method of deploying the RHEL rpms onto disk as a pseudo tree based image. Multiple OSTrees can reside on a disk at the same time. You select which of the installed trees you want to use on the next boot. It remove the granularity of yum package selection, and constraints you to the choice of content that was selected for inclusion in the tree at build/compose time.

      An OStree based host could run any type of service – containers (in RHEL Atomic Host), GNOME desktop (in upstream GNOME continuous integration environment), or even VM if the tree included the appropriate KVM/libvirt pieces.

      The Docker environment is independent of the OSTree environment. It is available in both an OStree based Atomic Host, and in regular RPM-based RHEL. Docker does not simulate anything inside the container. All the containers content must be included in the container at build time. The only expected resources for a Docker container is the kernel syscall interface..

      Hope this explanation helps.

      -regards
      Subhendu

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s