open containers

Jamie Duncan

Sr. Technical Account Manager




about, ground rules, scope

defining the problem

proposing the solution

selinux, cgroups, and namespaces

usage basics and examples

tools and inspection

dockerfiles and automation

rhel atomic host

conclusions and q&a

custom images

in the real world

about jduncan

@rh_jduncan |

I've been at Red Hat just over 3 years

I live in Richmond, VA

I work almost exclusively with Red Hat's Federal Governement customers

RG3 is going to have a monster year

ground rules

Today is a discussion, not a lecture. 

The technology revolving around containers is some of the fastest moving in the world, currently. I update this presentation every time I give it, and when I "went to press" it was accurate to the best of my knowledge.

In the end, it's all about learning some new information and having a couple of laughs. So let's do that.


There WILL be a demo towards the end

What you should expect from today

Yes... that was the Kiss of Death.

The goal of today's discussion is to help everyone understand WHAT containers actually are, so you can think it through better when it comes to utilizing them in your environment.

(Assuming we have time) We will also talk about RHEL Atomic Host, and how it is special compared to a standard RHEL installation.

In the end, the goal for this talk is to boost your confidence when you sit down to start working with containers in earnest.

defining the problem



"we need more apps faster! and spend less money!"

"we have to be compliant and secure! and spend less money!"

The Business




The Thunderdome

Proposing the SOlution



"we need more apps faster! and spend less money!"

"we have to be compliant and secure! and spend less money!"

The Business




Dev Ops
Happy Land

the current reality

Containers are already Standard Procedure for many of the biggest IT shops, and are far from new.

Google launches around 2,000,000,000 containers per week with their in-house solution

Google has been working on this for a decade.

Containers come in many flavors

Let Me Container That For You (LMCTFY)

LXD (Canonical/Ubuntu)

SELinux (yup, it's a container)



containers defined

Container managers like docker are applications that manage a set of tools that have existed within Linux for a long time to better isolate your applications. Tools like...



Kernel namespaces

So let's containerize all of the things! What does that mean?


Kernel Control Groups (cgroups), allow sysadmins to have fine-grain control of the resources available to an application, user or group.

You can control access to system memory, CPU time, network access, and block devices. 

In RHEL 7, cgroups are tightly integrated into systemd

For a great introduction to cgroups, check out the
RHEL 7 Resource Management and Containers Guide.


No, it's not just that thing you disable automatically.

For a deep walk through, please see the
RHEL 7 SELinux Guide

SELinux is a kernel feature that allows for Mandatory Access Control within a Linux system.

Also, please read carefully.

kernel namespaces


Kernel namespaces are the hardest concept to grasp when talking about containers. To users, they provide most of what we think of as 'isolation' to an application running in a container. We are concerned with 5 namespaces:

Mount Namespace

UTS Namespace

Network Namespace

IPC Namespace

PID Namespace

mount namespace

Mounting and unmounting filesystems will not affect the rest of the system.

Many systems use the mount namespace already with the 'PrivateTmp' feature that allows each user to have their own private temporary directory.

Inside a container, an application has its own versions of /etc, /usr, etc. that only have what it needs to run, and it doesn't affect any other containers or the host.

uts namespace

Using the UTS namespace, each container can have its own hostname and domainname.

This is really helpful for things like DNS, and to keep confusion to a minimum in general.

network namespace

Each container gets its own independent IPv4 and IPv6 stacks, routing tables, firewall rules, /proc/net, /sys/class/net, sockets, etc.

That means network isolation for the container, all the way through the kernel.

IPC namespace

The Inter-Process Communication (IPC) namespace in the kernel allows for each containerized application to have its own shared memory segments, semaphore sets, and message queues.

In short, each container has effective memory isolation from any other container or the host.

pid namespace

Each container gets its own PID counter set. 

Processes started within the container belong to this set of PIDs, but nothing else does.

Each container gets its own PID 1.


putting it all together

SELinux for Mandatory Access Control.

CGroups for resource limits

mount namespace so each container gets its own mountpoints.

uts namespace so each container can have its own domainname and hostname

network namespace gives each container its own network stack

memory isolation with the IPC namespace

each container gets its own PID counter

modern linux containers

docker specifics

Docker images

Docker Images are read-only templates. We can use them as the starting point to build our containers, stacked on top of them like a layer cake.

RHEL 7 Running Docker Daemon

Docker Base Image (RHEL 7)

Layered Image 1 (RHEL 7 with HTTPD)

Container 1

Layered Image 2 (RHEL 7 with HTTPD + Config)

Container 2

Container 3

Container 4

Container 5

Container 6

getting docker images

Red Hat provides Docker Image repositories to make it more convenient. Pulling down a RHEL base image is as simple as ...

example one - Hello world

$ docker run rhel7 echo "Hello World"

We just launched a RHEL 7 docker container and executed a simple 'echo' command. And we didn't even break a sweat. 

example two - network stack

-v $volume:$container_volume - bind mount a system volume into the container

-i - give me an interactive shell

-t - give me a pseudo-tty terminal

--rm - remove the container once it has finished executing the command

example two -a webserver

-w - working directory inside the container

-d - detached mode. the container runs in the background

-p - port to open for the container 

--name - an easy to identify name for my container

running containers

docker ps gives you an inventory of all currently running containers on a system. In this example, you can see the container we just started named 'python_web' running and serving on port 8080 in our host system from port 8000 inside the container.

container inspection

$ docker inspect python_web

container inspection specifics

docker inspect --format='{{.NetworkSettings.IPAddress}}' python_web

common docker commands

Docker works to emulate command names and styles that we are all used to in the Linux world.

docker start

-a -- attach to a running container

-i -- give me an interactive session in the container

docker stop -- sends SIGTERM

docker kill -- sends SIGKILL

--signal can send SIGHUP, etc.

docker rm -- removes a container

docker rmi -- removes an image

docker <command> help -- intuitive and useful

custom docker images

Docker is designed to be customized. It is easy to create very specific custom images to use in different situations.

docker run -i rhel7 /bin/bash -c "yum -y clean all; \
yum -y install httpd; \
yum -y clean all"

commit and verify

$ docker commit -m "rhel7 with httpd" -a "Jamie Duncan" cee17388cf06 rhel7-httpd
$ docker images

using my new image

once you have your custom image, starting it up as a contain is as simple as using one of the base images. You just tell it what to do.

can i script it?

Yes you can. Dockerfiles are script-like configuration files that are used create containers quickly and programatically. 

1. Create a directory named 'mongodb' with a file named 'Dockerfile'

2. Add the following into mongodb/Dockerfile:

FROM rhel7
RUN yum -y install mongodb-server
RUN mkdir -p /data/db
EXPOSE 27017
VOLUME ["/data/db"]
CMD "mongod"

3. Tell docker to build your image.

$ docker build -t mymongo mongodb/

more dockerfile options

MAINTAINER - get credit for what you do

ENV - set environment variables

ADD & COPY - files from <src> to your container and <dest>

ENTRYPOINT - run a container like an application

USER - run commands as a specific user

WORKDIR - set the container working directory

ONBUILD - trigger events based on new builds

.dockerignore - much like .gitignore, used for exclusions in your applications

in the real world

containerizing a real world application

I created a small application named 'soscleaner'.

It obfuscates data in an sosreport, or any collection of files to help prevent transmission of sensitive data.

I decided to create a container image for soscleaner and upload it to docker hub so people could play with it more easily.

FROM fedora
MAINTAINER "Jamie Duncan"
VOLUME ["/var/tmp"]
WORKDIR /etc/yum.repos.d
RUN curl
RUN yum -y install soscleaner tar libtar; yum clean all
CMD /usr/bin/soscleaner -r /var/tmp $OPTIONS $SOSREPORT 


* This will be in whole or in part in Kyle Benson's Red Hat Insights tool from this morning.

live demo
(cross fingers)

project atomic

project atomic

maybe the coolest project name EVER

Atomic is a very specific implementation of RHEL with a small footprint, designed and optimized to run docker containers in a clustered environment.

Designed to be orchestrated within your new hybrid clouds (Hi, OpenStack!)



kubernetes - container cluster management

rpmtree - small atomic-based OS installs

systemd - no flame wars, please

how it's built

















important facts

It's RHEL. Just very specialized.

ABI and kABI are preserved

Containerized apps enjoy ABI stability

*except for docker and kubernetes

Hardware and Hypervisor certifications are inherited from RHEL 7

So are all of the CCP requirements and certification

ISV certification - subject to the container that's running

Lifecycle - 3 years

my atomic experience

Some of my observations so far...

It's a whole new world in there.

yum and rpm aren't installed on the host

but they are in container images

SPC's can be a little confusing at first

Super-Privileged Containers

They can see the host

Used to run things like sosreport and rsyslog

Kubernetes is neat

It's still a challenge

It can be really, really fast to spin up big environments

It's moving and growing SO FAST...


containers are not silver bullets

While they are a great tool that every team should add to their arsenal as soon as they can, there are some limitations currently.

Under some circumstances, root inside a container can also act like root outside of the container.

Not everything is isolated in a namespace right now

parts of the kernel filesystem like /proc and /sys


There is no completely secure way to know what you are getting when you download a docker image, yet.

The good news?

Red Hat is working on it!

We are the largest contributor to docker outside of docker,inc.

Containers themselves are not easily made into a cloud or managed within existing tools and workflows

can you trust what you pull?

Anyone can build a docker image registry and make it publicly available.

The biggest one out there is Docker Hub at 

Anyone can upload their images. It's the wild west out there.

Who built it?

Why was it made?

What is in it?

Who maintains it?

red hat is working on it

We are working to make it possible to have a fully trusted chain from the host operating system all the way up through the container images.



How can you validate what's in the host and the containers?

Will it compromise my infrastructure?

It 'should' work from host to host, but can you be sure?

Trusted source for the host and containers

Enterprise lifecycle for container content

Proven portability

Container Development Kit

open standards

In addition to the work Red Hat is doing with Linux Containers like we discussed earlier, we are also leaders in multiple other projects that shape how containers will evolve.

container format with docker

  • Interface for communications, configuration, data persistence, provisioning
  • Content Agnostic
  • Infrastructure Agnostic

orchestration with kubernetes

  • Orchestrate containers at scale
  • Define application topologies
  • Handle container networking
  • Manage container state
  • Schedule across hosts

register container discovery

  • Easily find and consume trusted container images
  • Federate consumption libraries
  • Promote consistency and re-use


Open Containers - Public

By Jamie Duncan

Open Containers - Public

RHEL 7 Containers and RHEL Atomic Host introduction

  • 907
Loading comments...

More from Jamie Duncan