A few months ago Red Hat released the Red Hat Enterprise Linux 7 Atomic Host, aimed at bringing enterprise rigor to the emerging container-based application delivery systems. Looking ahead to Red Hat Summit, there are over 10 sessions on containers including a hands-on lab with Red Hat Enterprise Linux 7 Atomic Host. So what exactly is an “Atomic Host” and what does it do for your environment?
Containers on Linux
You can make a simple analogy between Red Hat Enterprise Linux 7 Atomic Host and a Type 1 hypervisor, but instead of running virtualized guests, it runs containers. We need to understand a bit more about containers to move forward.
A container provides a segregated section of a host resources managed within the host kernel, without the overhead of providing simulated hardware. This means a process running in a container sees a world that appears to be a separate system, but in reality is seeing a filtered view of the based on kernel namespaces and capabilities. Separate users, file systems, networking, process tables can all be provided to a container. Or, a container can interact with the host resource, say mapping a directory from the host to provide as web content to nginx running in the container.
Ok, that’s fine from how the host system provides the resources to the container, what about the application running inside the container? This will differ slightly based on the container format, but we put the application and all of it’s dependencies inside the container. That’s our code, libraries, binaries, and any other operating services down the chain. Since we’re running an OS and kernel on our host, we can run slimmed down versions of the OS inside the container.
Hopefully you can already see a good use for containers: application deployment issues. If your application is carrying it’s operating environment with it, all it needs to run is a container engine that supports the format. And it should be fairly simple to publish in several formats. No more worries about conflicting libraries, incompatible patches, or the dreaded “works for me” syndrome. If it works in development, it will work in production.
Docker is the specific container engine that is currently supported by the Red Hat Enterprise Linux 7 Atomic Host. Docker provides:
• the daemon that runs a container (engine)
• format for building containers (images)
• a way to ship packaged containers (registries)
So an Atomic Host runs the Docker Engine to launch a Docker Image downloaded from the Red Hat Customer Portal. When someone’s talking about a Docker container, they’re talking a specific format of container. There are a lot of tools and information on getting started running and building Docker containers.
The base value for Docker is that it runs on a number of different platforms and environments, which means you can build your app and container on RHEL and run it in OpenStack with RHEL Atomic. You can easily create your Java app on EAP, bundle all the dependencies, and deliver it to production with minimal fuss. We can eliminate much of the “works for me” issues that can plague the software development life cycle.
Red Hat Enterprise Linux 7 Atomic Host also includes some other interesting changes to the standard RHEL environment. Red Hat Enterprise Linux 7 Atomic Host is delivered as an OSTree, meaning the RPMs are ‘pre-installed’ and you get a mainly read-only file system instead of a package to install on disk. Instead of using yum to update a package, you use atomic host to upgrade the entire host. For more details refer to the getting started guide in the customer portal.
This also means you can’t install additional software on the host so we have to approach management tools differently. Since we can expose any of the host resources we need, we can use a container running on the host to manage the host. This is called a superprivileged container (SPC). Contrasting with a privileged container that may need root level access to a particular device (say /dev/snd), we’d make the host root file system available to a superprivileged container for managing files in /etc.
Hopefully, you’ve got enough now to download a copy of Red Hat Enterprise Linux 7 Atomic Host and get started running your first Docker container. There’s a lot more to Atomic and Docker, so I’ll be writing more on this in the future. Much has already been written as well, so read as much as you can find. There are still a few things that I want to make sure you keep in mind as you explore Atomic hosts and containers.
There’s an OS in that container. Do you know which one? Does it meet your CoN? Has it been updated recently? Downloading containers from the Internet, even from a known source, doesn’t guarantee that the what’s inside the container is trustworthy. Containers that are built by other folks may not meet the standards that you follow when building applications. And you have no control over that, containers you haven’t built are black boxes. You can attach and see what’s inside, but meaningfully modifying them is tough.
Also the same mechanisms we take advantage of to build superprivileged containers can be exposure points. Containers are kernel namespace separation mechanisms, not security mechanisms. Dan Walsh of Red Hat is fond of saying “Containers don’t contain”. Red Hat are wrapping SELinux protections around Docker containers as a security measure.