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
...
Deployments:
● 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
...
Upgraded:
GeoIP-GeoLite-data 2017.10-1.fc26 -> 2018.01-1.fc26
NetworkManager 1:1.8.2-1.fc26 -> 1:1.8.2-4.fc26
...
Removed:
...
Added:
...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 ~]# rebootWhen 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
...
Deployments:
● ostree://fedora-atomic:fedora/26/x86_64/atomic-host
Version: 26.247 (2018-02-14 16:51:26)
Commit: 5d0283ee...
...
ostree://fedora-atomic:fedora/26/x86_64/atomic-host
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
...
Downgraded:
GeoIP-GeoLite-data 2018.01-1.fc26 -> 2017.10-1.fc26
NetworkManager 1:1.8.2-4.fc26 -> 1:1.8.2-1.fc26
...
Removed:
...
Added:
...
[root@localhost ~]# rebootThe 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
Upgraded:
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
...
Removed:
...
Added:
...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 \
fedora-atomic:fedora/26/x86_64/atomic-host
…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
[origin]
refspec=fedora-atomic:fedora/26/x86_64/atomic-hostIt 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 \
fedora-atomic:fedora/26/x86_64/atomic-hostTo 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'
!GeoIP-GeoLite-data-2017.10-1.fc26-noarch
=GeoIP-GeoLite-data-2018.01-1.fc26-noarch
...To deploy 26.230, drop the --preview option:
# atomic host deploy 26.230As 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 \
http://mirror.centos.org/centos/7/atomic/x86_64/repoThe operation to switch to CentOS is called rebasing:
# atomic host rebase \
centos-atomic:centos-atomic-host/7/x86_64/standard
# rebootThis 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
Deployments:
● ostree://centos-atomic-host:centos-atomic-host/7/x86_64/standard
Version: 7.1803 (2018-04-03 12:35:38)
Commit: cbb9dbf9c8697e9254f481fff8f399d6808cecbed0fa6cc24e659d2f50e05a3e
ostree://fedora-atomic:fedora/27/x86_64/atomic-host
Version: 27.122 (2018-04-18 23:34:24)
Commit: 931ebb3941fc49af706ac5a90ad3b5a493be4ae35e85721dabbfd966b1ecbf99
GPGSignature: Valid signature by 860E19B0AFA800A1751881A6F55E7430F5282EE4Now 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
…
Added:
nmap-2:7.60-7.fc27.x86_64
Run "systemctl reboot" to start a reboot
# systemctl rebootAfter the reboot, log in again. Then check that the RPM is installed and available:
# rpm -q nmap
nmap-7.60-7.fc27.x86_64Delete 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
Removed:
nmap-2:7.60-7.fc27.x86_64
Run "systemctl reboot" to start a reboot
# systemctl rebootAfter the reboot, log in again. Then check that the RPM is not available:
# rpm -q nmap
package nmap is not installedTask 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/apacheThe 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 ecc736143f0cTask 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:
NAME LOCAL VERSION REMOTE VERSION DIFFERS
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:
NAME LOCAL VERSION REMOTE VERSION DIFFERS
rhel7 7.4-129 7.4-129 NOIn 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:
/host/var/tmp/sosreport-c.12345-20180228004916.tar.xz
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/syslogThe 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 etcdThe 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 \
registry.access.redhat.com/rhel7/flannel
# atomic install --system \
registry.access.redhat.com/rhel7/flannel
# systemctl start flannel
# atomic containers list
CONTAINER ID IMAGE COMMAND
CREATED STATE BACKEND RUNTIME
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 flannelIn 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-rhel7Finally, 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 \
registry.access.redhat.com/rhscl/httpd-24-rhel7
...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 \
registry.access.redhat.com/rhscl/httpd-24-rhel7
...
Remediating target df5ff2793065d8bf2dd8d9ab9678fc17f7c8dadfed97197795dd4ffb08cafcda.
...For more information, see the Atomic CLI Reference Guide and Using OpenSCAP with the atomic scan command.
Comments are closed.