What's New in Red Hat Enterprise Linux Atomic Host 7.2.5

It's been a busy few weeks for us on the Atomic Host team, and we're excited to announce the release of Red Hat Enterprise Linux Atomic Host 7.2.5! This is a big one too. For those not familiar with our release cadence, we release a new version of Atomic Host every six weeks. This enables us to balance the reliability of Red Hat Enterprise Linux with exciting new features and capabilities from our Project Atomic upstream community in a production ready, supportable manor.

Now, let's walk through some key new features in Atomic Host:

Container Runtimes

In 7.2.5, the docker container engine has been upgraded to 1.10.3 and provides a wide range of capabilities including being able to run unprivileged, systemd-based containers.

In our previous release we announced that we will now release two versions of the Docker container runtime - “docker” and “docker-latest.” The standard “docker” package has tight integration and testing with Red Hat’s versions of Kubernetes and OpenShift.  For users who do not leverage Kubernetes or OpenShift integration, but want to follow the upstream Docker engine, we now provide the “docker-latest” package. Users can leverage “docker” or “docker-latest” and expect a stable, supported experience.

The “docker” package remains the default and is fully certified with OpenShift and Kubernetes, and typically moves at a slightly slower cadence than docker-latest. Red Hat does not consider Docker 1.11 to be stable enough for production workloads, so we are purposefully holding “docker-latest” at version 1.10.3. The Atomic team is tracking 1.12 closely and investigating its candidacy as the next version for the “docker-latest” package.

Runc has also been updated. For those not familiar with runc, this is the Open Container Initiative (OCI) runtime. It can be used as a standalone runtime and our future releases of docker will leverage runc by default.

Atomic Scan

Our customers often ask questions like, "how do I know what's running inside of my containers?” or “am I vulnerable to any CVEs?" Well, we are happy to announce the availability of Atomic Scan which enables Deep Container Inspection (DCI) through a simple CLI. Atomic Scan has a pluggable backend designed to enable multiple back end scanners. It's also integrates with the operating system below the Docker runtime to provide both security and performance benefits.

The release of Atomic Scan also coincides with the availability of two backend scanners.

Red Hat is releasing our OpenSCAP container scanner as a technology preview. OpenSCAP is capable of showing CVEs at the rpm layer of your images. The upcoming release of CloudForms, our container management platform, will enable OpenSCAP scanning across the enterprise.

Black Duck is also releasing a back end scanner. This demonstrates a third party can plug seamlessly into Atomic Scan. Their scanner goes beyond a manifest based discovery approach and provides users with insight into almost any open source component used in operating system user space itself as well as applications and libraries added by developers.

Look for more details on all our scanning technology and collaboration at Red Hat Summit.

OSTree

OSTree is the backbone of Atomic Host and the underlying technology that enables an ephemeral operating system that maintains state. In this release we have a new "admin-unlock" feature that creates an writable overlay filesystem over the read-only /usr. This functionality will not only speedup upstream development at project atomic.io, but provide a way for us to offer hotfixes via support.

Cockpit

Our zero-footprint, user interface for RHEL & Atomic Host has a slew of new features as well. In case you missed it in recent versions, Cockpit included support for OSTree upgrades & rollbacks. In version 108, strict Content-Security-Policy is set to enforcing for all components. Think of this as having something akin to an SELinux policy for your browser session to run in, and mitigate against browser based attacks. As a bonus, there’s nothing for the user to configure or worry about.

systemd

Thanks to the hard work of Dan Walsh and team, this is the first release that contains the OCI hooks that provide better systemd integration both inside and outside of docker containers. Why would anyone want to run a full init system inside of a container? Well, there are quite a few actually. One of the main advantages is there are a lot of users looking to adopt containers, but who either aren't able or ready to adopt a microservices architecture. Using systemd provides a sane way to have multiple processes running inside the container. Currently we see users using bash scripts or other unsupportable tools like supervisord to spawn multiple processes and we think this is a better way. Now running two programs together in a container is as simple as:

FROM rhel7
RUN yum -y install httpd mariadb mariadb-server; yum clean all; systemctl enable httpd mariadb
EXPOSE 80 3306
CMD [ "/sbin/init" ]

It was previously possible to do this, but only by running privileged containers and by presenting several volumes to the container. Now we just need to start /usr/sbin/init and let the oci-register-system hook make life easy. Another advantage of running systemd as PID 1 in a container is that it fixes the automatic reaping of zombie processes problem.

We’re excited about the release of Red Hat Enterprise Linux Atomic Host 7.2.5 and we invite you to come try it out. To get started with the latest version, check out the download page. Also, if you are new to Red Hat Enterprise Linux Atomic Host or containers, here’s the getting started guide. As always, please feel free to let use know if you have any comments or questions below!