10 tasks for running containers on Atomic Host

10 tasks for running containers on Atomic Host

Learn what you can do with Atomic Host, a container operating system that provides a secure foundation for running containers.

cubes coming together to create a larger cube
Image by : 



Get the newsletter

Join the 85,000 open source advocates who receive our giveaway alerts and article roundups.

This article was co-written with Maxim Svistunov.

Unlike a virtual machine, which includes an entire operating system, a container is meant to hold only the software needed to run an application. Therefore, to run a container efficiently and securely, you need an operating system that provides secure container services and acts as a foundation for running containers. One operating system developed for that task is Atomic Host.

Think of Atomic Host as a secure, specialized version of Fedora, CentOS, or Red Hat Enterprise Linux (RHEL). Its best use is to provide a reliable and easily upgradable operating system for running containers. Different formats of Atomic Host are available to run on anything from bare metal to a variety of cloud environments. With an Atomic Host system installed, you can use the docker command as you would on other container-enabled systems. However, Atomic Host also comes with an additional command called atomic, which expands what you can do with containers.

The atomic command is a special tool for working with Atomic Host systems and the images and containers on those systems. Like the docker command, atomic can be used to list, run, tag, push, pull, and delete containers and images. But atomic also has other features that let you:

  • Work with Atomic hosts: Verify, upgrade, roll back, and unlock Atomic Host systems
  • Manage images: Install (to run in pre-defined ways), update, verify, and scan container images
  • Operate on containers: List, update, and roll back

Additionally, a key feature that makes atomic different from the docker command is that it can work with containers that are not associated with the Docker daemon. Using atomic to install what are referred to as system containers, you can set up those containers to run before the Docker daemon starts or on systems that have no Docker daemon at all. As container runtimes become available to replace Docker (such as CRI-O), the atomic command will let you work with containers on those runtimes as well.

If you have never worked with Atomic Host before, stepping through the 10 tasks below should give you a good feel for what you can do with it. Start by acquiring and starting an Atomic Host image for one of the following operating systems:

Task 1: Upgrade and roll back Atomic Host

Usual Linux distributions use package managers, so updates happen package-by-package. Atomic is different: Updates happen to the whole filesystem tree at once. A filesystem tree is called an "ostree."

Ostree updates are atomic—if a system shuts down, it cannot be halfway through an update. You either have the previously used ostree ("old") or the ostree to which you are switching ("new"). The change from one to the other is instant. This is possible because, instead of modifying the "old" ostree, the "new" ostree is created alongside it. On the next reboot, the new one is used.

To get information about the current ostree, run:

[root@localhost ~]# atomic host status
● fedora-atomic:fedora/26/x86_64/atomic-host
                Version: 26.157 (2017-10-29 14:42:37)
                Commit: c099633883cd8d06895e32a14c63f6672072430c151de882223e4abe20efa7ca

The ostree technology (which manages ostrees) is similar to Git. The ostree currently in use is like a Git commit that has been checked out into the working directory. Also, each available ostree in history is like a Git commit that you can check out and use.

To upgrade Atomic, run:

[root@localhost ~]# atomic host upgrade
  GeoIP-GeoLite-data 2017.10-1.fc26 -> 2018.01-1.fc26
  NetworkManager 1:1.8.2-1.fc26 -> 1:1.8.2-4.fc26

This command is similar to git pull—it fetches and deploys the latest available ostree. In the output, you see new, upgraded, and removed packages with their versions. Until you reboot, the old ostree is in use. To start using the new one, reboot:

[root@localhost ~]# reboot

When you switch to another ostree, things such as configuration, container images, and user files are kept, and only files like executables and libraries change. In this way, switching to a different ostree is similar to upgrading packages on a normal Linux distribution.

Now log in and check the status again:

[root@localhost ~]# atomic host status
● ostree://fedora-atomic:fedora/26/x86_64/atomic-host
                Version: 26.247 (2018-02-14 16:51:26)
                Commit: 5d0283ee...
                Version: 26.157 (2017-10-29 14:42:37)
                Commit: c0996338...

The sign shows the current ostree is version 26.247, which corresponds to commit 5d0283ee. You also see the "old" ostree. Atomic always keeps two ostrees: the current one and the old one. 

It's easy to roll back to the old ostree:

[root@localhost ~]# atomic host rollback
Moving 'c0996338...' to be first deployment
  GeoIP-GeoLite-data 2018.01-1.fc26 -> 2017.10-1.fc26
  NetworkManager 1:1.8.2-4.fc26 -> 1:1.8.2-1.fc26
[root@localhost ~]# reboot

The system now uses the old ostree again.

You can compare ostree A to ostree B without upgrading from A to B. You do not even need to fetch A or B. Just run:

[root@localhost ~]# rpm-ostree db diff c099633 5d0283e
ostree diff commit old: c099633
ostree diff commit new: 5d0283e
  GeoIP-GeoLite-data 2017.10-1.fc26.noarch -> 2018.01-1.fc26.noarch
  NetworkManager 1:1.8.2-1.fc26.x86_64 -> 1:1.8.2-4.fc26.x86_64

You will get the same information as you would during an upgrade.

Task 2: Deploy an older Atomic Host

Upgrading to the newest ostree and rolling back are specific cases of the more general "deploy" operation. As in Git, where you can check out any commit, you can deploy an ostree of any version.

To list the available ostree versions, pull the ostree metadata:

[root@localhost ~]# ostree pull --commit-metadata-only --depth=-1 \

The last argument in the above command specifies the remote source of the ostrees. They are stored in the /sysroot/ostree/deploy/fedora-atomic/deploy/*.origin file. To find out what this argument is in your system, look inside this .origin file:

# cat /sysroot/ostree/deploy/fedora-atomic/deploy/*.origin

It is useful to compare RPMs packages between ostree versions, so pull the metadata about RPMs too:

[root@localhost ~]# ostree pull --subpath /usr/share/rpm --depth=-1 \

To list available ostrees, run:

[root@localhost ~]# ostree log fedora-atomic:fedora/26/x86_64/atomic-host
commit 5d0283ee9dda7d3e1d49b8b34376bd38d36c5e4774c06bb2155168cef7f08cbe
Date:  2018-02-14 16:51:26 +0000
Version: 26.247
(no subject)

commit 26957d49f289bdfe3c24ede92112a8c91a22a19f5cec860cd77190825cef3419
Date:  2018-02-13 17:27:26 +0000
Version: 26.246
(no subject)

Say you want to deploy version 26.230. It is helpful to first see how the packages in the current ostree version compare to those in 26.230. You can do this by running a preview of the deploy operation:

# atomic host deploy --preview 26.230
Resolving version '26.230'

To deploy 26.230, drop the --preview option:

# atomic host deploy 26.230

As with an upgrade, you must first reboot to run the new ostree.

Also, the rpm-ostree db diff command we used to compare the current ostree with the newest can be used for any two ostree versions.

Task 3: Deploy other Atomic Hosts

In Tasks 1 and 2, Fedora Atomic Host ostrees were deployed. But you can also deploy an ostree of another Atomic Host variant, such as a CentOS Atomic Host or a RHEL Atomic Host. This means switching to a different operating system, such as between the bleeding-edge Fedora and the stable CentOS Atomic Host or RHEL Atomic Host.

To switch, add the repository of the other Atomic Host variant, then switch to CentOS with this command:

# ostree remote add --no-gpg-verify centos-atomic \

The operation to switch to CentOS is called rebasing:

# atomic host rebase \
# reboot

This will get the latest CentOS ostree and deploy it, the same way as with a Fedora ostree. After rebooting, you will be running the CentOS ostree:

  # atomic host status
  State: idle; auto updates disabled
  ● ostree://centos-atomic-host:centos-atomic-host/7/x86_64/standard
                        Version: 7.1803 (2018-04-03 12:35:38)
                        Commit: cbb9dbf9c8697e9254f481fff8f399d6808cecbed0fa6cc24e659d2f50e05a3e

                        Version: 27.122 (2018-04-18 23:34:24)
                        Commit: 931ebb3941fc49af706ac5a90ad3b5a493be4ae35e85721dabbfd966b1ecbf99
                    GPGSignature: Valid signature by 860E19B0AFA800A1751881A6F55E7430F5282EE4

Now you'll track CentOS ostrees, so if you run atomic host upgrade, you will get an upgraded CentOS ostree, not a Fedora ostree.

To revert back to Fedora Atomic Host, do an atomic host rollback.

Task 4: Install packages

On Atomic, instead of using package management commands like yum and dnf to install software, you use rpm-ostree. In this task, you will install and delete RPM packages on your Atomic Host.

NOTE: On RHEL systems, register and subscribe the system before installing software.

Install a package

To install a package called nmap, type the following:

# rpm-ostree install nmap
Checking out tree da0bd96... done

Run "systemctl reboot" to start a reboot
# systemctl reboot

After the reboot, log in again. Then check that the RPM is installed and available:

# rpm -q nmap

Delete a package

To delete a package, use the rpm-ostree uninstall command:

# rpm-ostree uninstall nmap
Copying /etc changes: 17 modified, 0 removed, 36 added
Transaction complete; bootconfig swap: no deployment count change: 0
Run "systemctl reboot" to start a reboot
# systemctl reboot

After the reboot, log in again. Then check that the RPM is not available:

# rpm -q nmap
package nmap is not installed

Task 5: Managing images and containers

The atomic command simplifies management of container images and containers. What is the difference between container images and containers? The same as between commands in RPMs and processes that you start using those commands. For example, yum install vim installs the vim command (container image) that has the vim command, while vim file.txt starts an instance (container) using the vim command.

The following commands show how to manage container images on Atomic. The first command downloads the image, the second lists the image, and the final one deletes the image:

# atomic pull docker.io/fedora/apache
# atomic images list
# atomic images delete docker.io/fedora/apache

The following commands show how to manage container images on Atomic. The first runs a container from an image, the second lists running containers, the third stops a running container with ID ecc736143f0c, and the last one deletes the container with ID ecc736143f0c:

# atomic run docker.io/fedora/apache
# atomic containers list
# atomic stop ecc736143f0c
# atomic containers delete ecc736143f0c

Task 6: Update and verify images

Using atomic images verify, you can view both local and remote version information for a container image. If a more recent image is available from the registry than is available locally, you can update that image. Here's how:

# docker pull registry.access.redhat.com/rhel7/rhel
# atomic images verify -v registry.access.redhat.com/rhel7/rhel
registry.access.redhat.com/rhel7/rhel contains the following images:
rhel7    7.3-97                 7.4-129                 YES
# atomic images update registry.access.redhat.com/rhel7/rhel
Pulling registry.access.redhat.com/rhel7/rhel:latest ...
Copying blob sha256:9c …

# atomic images verify -v registry.access.redhat.com/rhel7/rhel
registry.access.redhat.com/rhel7/rhel contains the following images:
rhel7   7.4-129                 7.4-129                 NO

In this example, the local rhel7 image is for version 7.3-97, while a different version is available (7.4-129) from the registry. After you update the image, you can verify that the local version matches the remote version.

Task 7: Run privileged containers

The support-tools image is an example of a container that opens privileges to the host and lets you run tools not included in Atomic (such as sosreport and strace) from that container. This container totally opens access to the host features (IPC, network interfaces, and process table) and file system content (/run, /var/log, and so on) to the command you run (sosreport, in this example).

# atomic run rhel7/support-tools sosreport
docker run -it --name support-tools --privileged --ipc=host --net=host --pid=host -e HOST=/host -e NAME=support-tools -e IMAGE=rhel7/support-tools -v /run:/run -v /var/log:/var/log -v /etc/machine-id:/etc/machine-id -v /etc/localtime:/etc/localtime -v /:/host rhel7/support-tools sosreport
This container uses privileged security switches:
Your sosreport has been generated and saved in:
The checksum is: e1eb00750a5d44d7e8210c5a9a7ceae7
Please send this file to your support representative.

Some containers, including support-tools, are specially built to include a run variable. That variable sets the exact docker command to launch when you use atomic run to start it. You can use docker inspect to see that variable:

# docker inspect registry.access.redhat.com/rhel7/support-tools \
      | grep run
    "run": "docker run -it --name NAME --privileged --ipc=host --net=host --pid=host -e HOST=/host -e NAME=NAME -e IMAGE=IMAGE -v /run:/run -v /var/log:/var/log -v /etc/machine-id:/etc/machine-id -v /etc/localtime:/etc/localtime -v /:/host IMAGE",

Task 8: Install super-privileged and system containers

Some special containers, built for use by atomic, can be "installed" on an Atomic Host to run as defined by information inside the container. These include:

  • Super-privileged containers: Containers that have extra privileges (can access or modify the host system) and include an install step to prepare the system to run the container

  • System containers: Containers that are set up in an install step to be managed by systemd, so they can start automatically when the system boots and run continuously without requiring a Docker service

Install and run a super-privileged container

The atomic install command sets up a super-privileged container to run by pulling the image to the local system and running a script to set up the host system for the container to run. For some containers, this includes creating configuration files. The atomic run command then runs the container using preset options from inside the container to open extra host privileges.

For example, to configure the rsyslog container, run:

# atomic install registry.access.redhat.com/rhel7/rsyslog
Pulling registry.access.redhat.com/rhel7/rsyslog:latest ...

Creating directory at /host//etc/pki/rsyslog
Installing file at /host//etc/rsyslog.conf
Installing file at /host//etc/sysconfig/rsyslog
Installing file at /host//etc/logrotate.d/syslog

The atomic run command runs the container, using preset options from inside the container:

# atomic run registry.access.redhat.com/rhel7/rsyslog
docker run -d --privileged --name rsyslog --net=host --pid=host -v
/etc/pki/rsyslog:/etc/pki/rsyslog ...

In case of super-privileged containers, such as rsyslog, the container has extra privileges on the host. The result is that the rsyslogd daemon is running with access to configuration files and log files on the host. See the full docker command output after the atomic run command. For more on super-privileged containers and descriptions of privileged options, see Running Super-Privileged Containers.

Install and run a system container

Some containers need to start before the Docker service starts or start on a system with no Docker service. Use atomic install to set up a system container, which bypasses the docker service entirely and uses the systemd service to start the container.

Here's an example of the etcd system container.

# atomic pull --storage=ostree registry.access.redhat.com/rhel7/etcd
Pulling layer 9a32f102e6778e4b3c677f1f93fa121808006d3c9e002237677248de9acb9589
# atomic install --system registry.access.redhat.com/rhel7/etcd
Extracting to /var/lib/containers/atomic/etcd.0
systemctl daemon-reload
systemd-tmpfiles --create /etc/tmpfiles.d/etcd.conf
systemctl enable etcd
# systemctl start etcd

The result is that the etcd service starts and runs continuously, then restarts every time the system is rebooted. For more on system containers, see Running System Containers.

Task 9: Update and roll back containers

If you have set up a container to run on your system, and a new version of that container becomes available, you can update it without having to repeat the pull and install steps. Here's an example:

# atomic pull --storage=ostree \
# atomic install --system   \
# systemctl start flannel
# atomic containers list
CONTAINER ID IMAGE                        COMMAND  
flannel       registry.access.redh flannel      /usr/bin/f
   2018-02-28 16:48 running  ostree   /usr/bin/r
# atomic containers update flannel
# atomic containers rollback flannel

In this example, after the flannel container is pulled, installed, and started, listing containers shows that the flannel container is running and is an ostree type. When a new flannel container image is available, you can use the update option to grab the new container. If you want to return to the old container, use the rollback option.

Task 10: Scan images

The atomic scan command does security scans of container images and containers. The command can use different scanners in the backend. This example uses the openscap scanner. Note that openscap works only with container images and containers based on the rhel container image.

First, install the openscap container image:

  # atomic install registry.access.redhat.com/rhel7/openscap
  docker run --rm --privileged -v /:/host/ registry.access.redhat.com/rhel7/openscap sh /root/install.sh registry.access.redhat.com/rhel7/openscap

Second, download without installing the image that you will scan. In this example, an Apache web server container image will be scanned:

  # atomic pull registry.access.redhat.com/rhscl/httpd-24-rhel7

Finally, scan the Apache image with the openscap scanner:

  # atomic scan --scanner openscap registry.access.redhat.com/rhscl/httpd-24-rhel7
  registry.access.redhat.com/rhscl/httpd-24-rhel7 passed the scan

Files associated with this scan are in /var/lib/atomic/openscap/2018-04-29-22-38-58-453732.

The above command scanned the container image for Common Vulnerabilities and Exposures (CVEs). It is the default scan type. There are two other scan types: scanning for configuration compliance and remediating configuration compliance.

To scan for configuration compliance:

  # atomic scan --scanner openscap \
       --scan_type configuration_compliance \

The following issues were found:

        Ensure Software Patches Installed
        Severity: Important
        XCCDF result: notchecked

Files associated with this scan are in /var/lib/atomic/openscap/2018-04-29-22-39-21-584104.

To remediate configuration compliance:

  # atomic scan --scanner openscap \
       --scan_type configuration_compliance --remediate \
  Remediating target df5ff2793065d8bf2dd8d9ab9678fc17f7c8dadfed97197795dd4ffb08cafcda.

For more information, see the Atomic CLI Reference Guide and Using OpenSCAP with the atomic scan command.

About the author

Christopher Negus - Linux book author, Red Hat Certified Architect. Works for Red Hat, soccer enthusiast, singer, husband and father.