Differences between RHEL Server and RHEL Atomic Host

Updated -

Red Hat Enterprise Linux Atomic Host (RHEL Atomic Host) is a variant of Red Hat Enterprise Linux Server (RHEL Server) designed and optimized to run Linux Containers. On the surface both variants look quite similar.

Red Hat Enterprise Linux Server is designed as a general purpose operating system for all of your applications and some customers are running 1000s of instances in production - RHEL Server provides flexibility to configure each of the instances as necessary for its workload. This flexibility comes at a cost, management is fundamentally more complex and handled with more traditional tools.

RHEL Atomic Host is designed around a different deployment, operational, and management paradigm that makes it manageable at hyperscale. All RHEL Atomic Hosts are designed to be configured upon deployment and managed identically. It is designed to be easily configured with automation which is useful in a completely ephemeral environment such as private cloud, public cloud, or even as a virtual machine on a developer’s laptop. It’s meant to be updated transactionally, with pre-tested, packages. Combined, this makes RHEL Atomic Host manageable in large distributed systems environments where control over any individual host is limited. This is useful whether you have an instance running on a developer's laptop, or 10,000s of hosts in production.

Technical Details

The biggest difference between RHEL Server and RHEL Atomic Host is that RHEL Atomic Host is built around the design principles of distributed systems. When building clusters of container hosts, configuration consistency and incremental scalability are critical. These principles allow administrators utilize commodity hardware or cloud servers to quickly recover crashed nodes or add nodes as capacity to the cluster when they need to scale up. To achieve configuration consistency and incremental scalability, RHEL Atomic Host starts with some specific design constraints - a read only file system, a minimal package set, and a single command to manage host upgrades/downgrades.

First, the read only file system helps ensure consistency across the entire environment because unwanted file system changes are prohibited. Updates are delivered, not through RPMs, but via immutable, bootable sets called operating system trees (ostrees). Red Hat Engineering builds these ostrees from RPM content, then tests, and releases them as immutable objects. This ensures that a RHEL Atomic Host is always upgraded from a known, good starting point, to a known good destination. Having the exact same package set on all of the hosts ensures smooth and effortless upgrades, even in very large clusters - less permutation, means less problems. RHEL Atomic Host does not include yum or any other package manager because updates and rollbacks are performed transactionally with the "atomic host” command.

Second, RHEL Atomic Host has a lean package set - this helps ensure consistency throughout a production environment, minimizes permutations, and makes it small, quick, secure, and manageable. The packages used in RHEL Atomic Host ostrees are chosen from a subset of the exact same RPM content used in RHEL Server - this ensures the same quality of software for RHEL Atomic Host and ensures kernel and user space compatibility. The set of packages is comparable to a Minimal Install of RHEL Server, but not identical - here is an approximate comparison of packages between RHEL Server vs RHEL Atomic Host packages. All updates and rollbacks of ostrees are managed with the atomic command.

Finally, the atomic command provides a unified entrypoint to managing both RHEL Atomic Host as well as the container images which are cached, installed, and run locally. To upgrade RHEL Atomic Host, an administrator uses the atomic host upgrade - this command, in turn, leverages the rpm-ostree tooling to download ostree layers from a repository managed by Red Hat. It’s worth noting that only the file-level delta between the running ostree and the upgrade are transferred. This is incredibly efficient from a network perspective and beneficial for minimizing bandwidth usage for disperse systems. When you upgrade, the latest ostree is made available and then deployed the next time you reboot. By default, the system keeps the newest two ostree layers locally downloaded and if there is an emergency in your cluster, you can use the atomic host rollback command to recover.

Adding Software

RHEL Atomic Host is designed to fit nicely into an immutable infrastructure - it provides an immutable host maintained and updated by Red Hat. Many of the tools you might want to use might not be part of the ostree - that’s ok, because this allows developers, architects, and systems administrators to focus on adding software through containers. Containerizing additional needed software keeps the system lean and manageable.

However, there are a few options which provide flexibility to Atomic - Super-Privileged Containers and package layering . The Super-Privileged Containers can access the host in order to monitor or troubleshoot the host. The RHEL Atomic Tools container is provided by Red Hat and has many debugging tools like sosreport, traceroute, strace, tcpdump. As a fallback for software that is difficult to put in a container, RHEL Atomic Host has something called package layering. Using the atomic host install [rpms] command lets you install packages that are not part of the original ostree. Dependencies are automatically resolved for these packages and during ostree upgrades, the system will check for updates for these packages in one operation. Layered packages persist across upgrades of the host (and package updates are checked at host upgrade time).

Preinstalled Tools

  • RHEL Atomic Host comes pre-installed with all the tools for running containers - docker, runc, kubernetes client, etcd, flannel, atomic. Orchestrating containers via Kubernetes is supported in a single master/node deployment on a single system. Larger, multi-system environments use OpenShift Container Platform to provide multi-host, container orchestration. Additional details about supported container orchestration tools can be found at How are container orchestration tools supported with Red Hat Enterprise Linux?.

  • RHEL Atomic Host has comes pre-installed with container performance tuning profiles, Ceph & Gluster storage clients, SSSD, and iSCSI tools.

Operating System Content

  • The operating system content is delivered as an immutable ostree. Any additional software not found in the ostree should be run from inside of a container. This may require the use of the --privileged docker option or a Super-Privileged Container such as the RHEL Atomic Tools container for software that cannot be run from a container.

  • The yum command is not present in RHEL Atomic Host and cannot be used to install packages. However, it is still possible to use the rpm command to query packages installed in the immutable ostree. Note that Yum is available inside RHEL-based container images.

  • As a fall back, it is possible to install RPMs on the system using the atomic install command. This is highly useful for troubleshooting a system that is misbehaving.

  • RHEL Atomic Host supports atomic upgrades and rollbacks of the OS. You can power off the system during an upgrade/rollback operation and it will still be functional during the next boot. RHEL Server is not as fault-tolerant during upgrades and does not have robust rollback support. This is useful in large distributed systems.

  • On RHEL Atomic Host, there are two new directories in root (/): the /sysroot/ directory, and the /ostree/ directory.

  • The atomic host deploy command is available on Atomic Host which lets you choose a specific version of an ostree, bringing more flexibility than upgrade and rollback. For example, you can the following command to deploy a particular version of RHEL Atomic Host:

      # atomic host deploy 7.2.7
  • No man pages - To save storage space, manual pages are not shipped with the Atomic Host image. However, the RHEL Atomic Tools container has the man pages for the packages that make up the ostree and you can access them by running the container:

      # atomic run rhel7/rhel-tools man rpm-ostree

System Management

  • Cockpit is a powerful, modern web UI for RHEL and RHEL Atomic Host. The web frontend is delivered as a container for Atomic Host and provides an interface that makes administering containers a breeze for admins who come from a virtualization background.

  • From the boot prompt, Atomic Host has the ability to go straight into the Cockpit UI via Developer Mode. This provides developers with configuration free access to get started with containers. See Chapter 2 of the Red Hat Enterprise Linux Atomic Host 7 Installation and Configuration Guide for additional information about Developer Mode.

  • There are only two writable directories for local system configuration: /etc/ and /var/. All other directories on the system are read-only. User and host specific data that is intended to persist across updates should be stored only in the /var/ directory. For example, the /home directory is symlinked to /var/home and therefore is writable as usual. Configuration files in the /etc/ directory can still be modified as usual.'

  • The storage configuration of RHEL Atomic Host uses LVM by default. During installation, two Logical Volumes (LV) are created. The root LV is used for the operating system content. The "docker-pool" LV is thinly-provisioned and is configured to grow automatically. The "docker-pool" LV is used as the storage backend for Docker. The Docker storage configuration is managed via the atomic CLI and/or Cockpit.

  • RHEL Atomic Host provides a choice between docker and docker-latest, but Red Hat does not support running both docker and docker-latest on the same machine at the same time.

  • There are two new tuned profiles optimized for Atomic, atomic-host for physical machines and atomic-guest for virtual machines.

Common Strengths

Security - SELinux is enabled by default on both RHEL Server and RHEL Atomic Host. SELinux provides strong safeguards in multi-tenant environments. The iptables services are available as a firewall, iptables is turned off by default. The atomic scan command is available on both systems (on RHEL Atomic Host it is pre-installed) to check if your containers comply with the security policies, and if they have vulnerabilities.

Support - RHEL Atomic Host is included with RHEL Server subscriptions at no extra cost. End users can gain access to support through phone or the Red Hat portal with the same level of support as RHEL Server.

Same RPMs - RHEL Atomic Host is built using a subset of the exact same RPMs that are used in RHEL Server, however their content is delivered in the form of an immutable ostree. This allows administrators to leverage their RHEL knowledge but still gain the manageability of an immutable system in a large distributed system.

I Want To Run Containers. How do I know which RHEL I need?

If you want to build containers - RHEL Server or RHEL Atomic Host
If you want full-blown build environment - CDK, RHEL Server

If you want to run containers in production in a large distributed system - RHEL Atomic Host
If you want to run containers in production, but can’t add another operating system variant - RHEL Server


Whoever wrote this article (I have a much more descriptive name for it) needs to learn what it is to 'write to your audience'. There are so many Redhat specific buzzwords in here as to make the article arcane and indecipherable. Not all of us administrators eat, sleep, breathe Redhat. So 'dumbing it down' would be welcome here. For example: "RHEL Atomic Host is designed around a different deployment, operational, and management paradigm that makes it manageable at hyperscale." What does that mean in English? I read sentences like that, and my eyes glaze over. I have to re-read it multiple times to be able to grasp what the author is trying to say. I came to this page to try to find out what an Atomic Host is, and why someone would want one. I don't want to have to work on comprehending the tossed salad of jargon and buzzwords contained in this article.

Another example: "It is designed to be easily configured with automation which is useful in a completely ephemeral environment such as private cloud, public cloud, or even as a virtual machine on a developer’s laptop." Huh? Find a less lofty way of writing, please.

About halfway through the article, I gave up, and determined that if I can't even understand the definition, I certainly don't want to try to understand the application of whatever the author is trying to "explain".

I read this article, with my 20+ years Unix systems administration experience, I find it a succinct enough message. I've been a long time Red Hat supporter (Enterprise level) and I can say for certain their products speak for itself. They don't need fancy words to describe their usefulness.

Perhaps what RH should have done is mark this article reading level to "technical" or "semi-technical" instead of the "general" designation. That way it's fair warning to those who find it TL;DR.

The para 'Finally, the atomic command provides' under 'Technical Operations' has a link for 'atomic' word which points to 'qa.redhat.com' which seems to be unavailable for outside RH domain. Small mistake but needs to be corrected.