Last week, the CentOS Atomic SIG released an updated version of CentOS Atomic Host (tree version 7.20160707), featuring updated versions of docker and the atomic run tool.

CentOS Atomic Host includes these core component versions:

• docker-1.10.3-44.el7.centos.x86_64
• kubernetes-1.2.0-0.12.gita4463d9.el7.x86_64
• kernel-3.10.0-327.22.2.el7.x86_64
• atomic-1.10.5-5.el7.x86_64
• flannel-0.5.3-9.el7.x86_64
• ostree-2016.5-3.atomic.el7.x86_64
• etcd-2.2.5-2.el7.0.1.x86_64
• cloud-init-0.7.5-10.el7.centos.1.x86_64

CentOS Atomic Host is available as a VirtualBox or libvirt-formatted Vagrant box, or as an installable ISO, qcow2 or Amazon Machine image. Check out the CentOS wiki for download links and installation instructions, or read on to learn more about what’s new in this release.

OCI Advances: runC and OCI Hooks

CentOS Atomic Host now ships with runC, a lightweight client wrapper around libcontainer for spawning and running containers according to the Open Container Initiative specification. In this release, the host’s atomic run tool makes use of runC to manage system services running in containers. While it’s possible to run system containers with docker, there are certain system components that present chicken-and-egg scenarios, such as flannel, on which docker itself depends.

runC-based containers can be pushed and pulled from standard docker registries, but are composed slightly differently than standard docker containers, as described in this post from Mrunal Patel, and this Dockercon 2016 talk from Phil Estes.

For more information on the system container feature in atomic, check out the man page for the atomic install command and this blog post from Giuseppe Scrivano.

Elsewhere on the OCI front, users who wish to run systemd inside of their containers can do so more simply with this new atomic host release, thanks to a pair of OCI hooks that enable users to run systemd in docker and OCI compatible runtimes such as runc without requiring the --privileged flag, and to display journal information from these containers using the host’s journalctl command.

Modifying the Host & CentOS Atomic Continuous

Also new in CentOS Atomic Host is an updated version of OSTree, the project that provides for atomic system upgrades for Atomic Hosts. The new OSTree version adds support for the ostree admin unlock command, which mounts a writable overlayfs, allowing users to install rpms on their otherwise immutable atomic hosts. These overlaid packages can be made either to persist between reboots or not, but the overlay will be discarded following an ostree upgrade. For more information on this feature, check out Jonathan Lebon’s blog post on hacking and extending atomic hosts.

For a more permanent package overlay option, there’s a brand-new package layering capability available, which Jonathan also covers in his post. However, this capability is not yet included in the main CentOS Atomic Host release.

To facilitate the testing of this and other new atomic host features, the SIG is now producing a Continuous atomic host tree, which combines a base of CentOS packages with an overlay of certain continuously-built packages pulled from upstream git sources. The packages are built using a project called rpmdistro-gitoverlay that runs as a Jenkins job within the CentOS CI infrastructure.

Switching to the Continuous release involves adding a new remote entry to an existing atomic host, rebasing to the continuous tree, and rebooting into the new tree:

# ostree remote add --set=gpg-verify=false centos-atomic-continuous https://ci.centos.org/artifacts/sig-atomic/rdgo/centos-continuous/ostree/repo/
# rpm-ostree rebase centos-atomic-continuous:centos-atomic-host/7/x86_64/devel/continuous
# systemctl reboot

Many of the features that make Atomic Host great are due to the immutability of /usr. Things like atomic upgrades and rollbacks and efficient storage of files in an object store all require immutability. However, this immutability is also what can irritate people the most when they first start using Atomic Host. There is no yum or dnf to install programs. We are at the mercy of the content provider.

The answer of course is to use containers. Keep a “pet” SPC container around that will allow you to do all the configuration and hacking you need, all in the comfort of your favourite editor.

But if you’re hacking on the Atomic Host itself, containers can only take you so far. What if you want to change the version of docker on the host? Or install a new package? Or modify an installed Python script for debugging?

I recently answered an email asking about –selinux-enabled in the docker daemon, I thought others might wonder about this, so I wrote this blog.

I’m currently researching the topic of --selinux-enabled in docker and what it is doing when set to TRUE.

From what I’m seeing, it simply will set context and labels to the services (docker daemon) when SELinux is enabled on the system and not using OverlayFS.

But I’m wondering if that is even correct, and if so, what else is happening when setting --selinux-enabled to TRUE.

``–selinux-enabled on the docker daemon causes it to set SELinux labels on the containers. Docker reads the contexts file /etc/selinux/targeted/contexts/lxc_contexts` for the default context to run containers.

Cockpit is the modern Linux admin interface. There’s a new release every week.

Here are the highlights from this week’s 0.111 and 0.112 releases.

Last month we introduced Commissaire giving a quick overview of features and architecture.

If you’re at Red Hat Summit, you might want to come by the Atomic Pod in Community Central and see the Sub-Atomic Cluster. More usefully, we’ll be having a series of live demos by various contributors to the Atomic suite of projects, including:

• Tuesday, 12:45pm: Using Cockpit to manage Kubernetes and Registry with Stef Walter and Peter Volpe
• Tuesday, 4:45pm: Fully automated configure of Kubernetes with Ansible, Jamie Duncan
• Tuesday, 6:00pm: Atomic Scan with Dan Walsh
• Wednesday, 12:15pm: Container Security Tools with Mrunal Patel
• Wednesday, 6:00pm: Atomic Scan with Dan Walsh
• Thursday, 11:00am: Building Multi-container Apps with Dusty Mabe

The Atomic Pod is in Community Central on the main expo floor, right next to the OpenShift Corner.

We will be attempting to schedule additional demonstrations as folks become available, so check back on this page for more.

On the 15th of June, over 60 brave souls gathered together and in defiance of an absolutely gorgeous summer day, talked about containers. Four speakers presented a very different set of talks covering all areas of containers from development to management to deployment.

Jiří Sedláček, an agile QA specialist and developer at Wandera, presented "Development and Deployment Simplification with Containers" (slides). At a previous company, he and the team implemented a docker-driven development environment that helped change the operational philosophy from the bottom up.

Since Atomic Registry was announced as the enterprise, 100% open source private docker registry, we have been responding to feedback from the community to make it great. The Cockpit team has been working hard to improve the console interface and general user experience. The OpenShift team has been tirelessly updating the backend to make the registry more stable, usable, and easier to deploy and maintain.

Some of the feedback we received suggested the deployment method was difficult to understand. As part of OpenShift it pulled in a lot of dependencies that were not essential for running the registry. The OpenShift features are terrific for running clustered container workloads but it can be a barrier to some administrators for just running a standalone registry.

I’m continuing to kit out the Sub-Atomic Cluster, in the process it’s received some upgrades. Thanks to John Hawley of the Minnowboard Project at Intel, I now have a nice power supply instead of the tangle of power strips, and in a couple days I’ll also have more SSD storage. You can see here that one node is in a nice blue metal case: that’s Muon, which we’ll be raffling off at DockerCon. Come by booth G14 to see the cluster and for a chance to win the Muon!

While I’m waiting for those, though, I might as well get this set up as a proper Kubernetes cluster. Ansible is my tool for doing this.

This release of Atomic App introduces a large code-base change related to our Kubernetes provider.

We incorporate major changes to the Kubernetes provider. With this release, we replace the usage of kubectl with the requests Python library and the Kubernetes HTTP API end-point. This change results in faster deployment, smaller image sizes, and increased detail in logging messages.

The main features of this release are:

• Kubectl to API conversion
• Removal of ASCII art