Building an OpenShift Lab: Why I Used Atomic Host

Over the last two days, I have been building an OpenShift environment which will be used for our Container Internals lab at Red Hat Summit. It’s a seven node setup with an haproxy, three masters and three worker nodes. This going to be a great environment to teach people the deep, dark, magical secrets of how containers work as well as a quick introduction to distributed computing. This leads me to the reason why I chose Red Hat Enterprise Linux Atomic Host. There are a lot of things that people don’t think about when preparing a distributed systems cluster and the less things to configure, the less that can go wrong at scale.

Looking at the OpenShift installation instructions, you will quickly notice that RHEL Atomic Host requires a lot less configuration than a full RHEL Server installation. The docker daemon is installed and configured, storage is already setup to use device mapper on a dedicated LV, and the default tools necessary to install OpenShift are already on the system. And as a bonus, the installation on my laptop in KVM virtual machines is about 10X as fast as running a minimal RHEL installation. After the very quick installation of RHEL Atomic Host, all the administrator has to do is configure networking, expand storage, and distribute ssh keys. If you want to take a look at the details of how easy it is to set up a lab, I documented them here.

 

 

The above reasons are why I chose Atomic Host for my lab. This is not to say that there are not challenges with Atomic Host. It takes some real getting used to, running everything from containers. And if you are like me, you will experiment with Super Privileged Containers and break some things on the host. As a cautionary tail, do NOT try things like:

docker run -v /root:/root:Z -it rhel7/rhel-tools bash

This can lead to some very strange SELinux problems which are harder to troubleshoot in Atomic Host. Generally, be very careful not to change SELinux contexts on files in /root or /etc as I have not found an easy way to fix them if you break something. I learned the hard way, because I tried relabeling files as if I was using RHEL. This is a big mistake because large parts of the file system are read only.

It takes some getting used to, when you are adopting an immutable (generally, there are ways around this) operating system like RHEL Atomic Host, but the trade off’s are well worth the effort. At scale and when you need to bring up infrastructure quickly, the limited scope and immutable nature of RHEL Atomic Host is a benefit. There is an old saying in music, “it’s not the notes you play, it’s the notes you don’t play” and the same is true with RHEL Atomic Host. If you are just starting out with containers, or you are a Kubernetes guru, I suggest checking out the Atomic Host versions of RHEL, CentOS, and Fedora. I would love to hear your feedback on Atomic Host and/or OpenShift, so leave a comment below…