OpenShift on OpenStack

Using Heat, Docker and Kubernetes to Simplify Your Life and Accelerate Development

Presented by
Diane Mueller, Red Hat OpenShift / @pythondj
Daneyon Hansen, Cisco / @daneyonhansen

Today's Agenda


Important Stuff

  • Who We Are
  • Why We Love OpenStack
  • Where all the Cool Stuff is on GitHub


You are OpenStack Saavy, so..

  • You know a little about Heat
  • You are either devs or ops or both
  • You know what GitHub is
  • You've heard of Docker ;0)'

Optional Skillz:

  • git
  • Docker
  • Kubernetes
  • Golang

Part 1: PaaS On OpenStack?

Cloud Services

Why Put a PaaS on OpenStack?

  • Improve IT's productivity
  • Build and Deploy Applications Faster
  • Maintain Flexibility
  • Drive Down Cost of IT
  • Meet Developer Expections

Automation, Automation, Automation

is Not Enough

  • Servers in the Cloud
  • You build and manage everything
    (OS, app servers, DB, application, etc.)


  • Someone else's app, hosted in the cloud
  • You are restricted to the features of the application—
    You get what they give you., Google Apps, iCloud


  • Quickly build (or try out) the applications that you need.
  • Code applications that can live on a hybrid cloud.
  • Leverage the ease, scale and power of the Cloud.
Code   Deploy   Enjoy

The 3 Flavors of OpenShift

What can you do with OpenShift?

How Does It Work?

It starts with multi-tenancy via linux containers...

How Does It Work?

...and adds central management with easily scaled deployments

Heat: Putting the PaaS in OpenStack

Cross Community Collaboration

Heat Overview

  • Provides AWS CloudFormation and native ReST API
  • Abstract configuration of services into a simple template
  • HA/auto-scaling/monitoring features

OpenShift Origin Heat Templates

OpenShift Enterprise Heat Templates

Watch it at your leisure here on YouTube

OpenShift V2 on OpenStack on YouTube

So Why a New PaaS?

  • Live and learn
  • New tools
  • Sweet user experience + awesome technologies = Happiness

First PaaS Component: Docker Logo

What is a Container?

Diagram of a multi-layered docker container
  • In the Docker world, a container is a running instance of an image
  • Based on linux containers (namepaces, control groups)
  • A file system layer cake, aka a "Union File System"
  • Includes all of the components necessary to run a process, store persistent data, or both

Images: More like git than tar

  • Pull and Push
  • Versions and Tags
  • diff a container

Versioning / Tagging

Find the image ID:

$ docker images
REPOSITORY          TAG                 IMAGE ID            CREATED             VIRTUAL SIZE
danehans/nodesrv    v1                  fe809d275af3        18 hours ago        864.9 MB
node                latest              32b8e915efd9        3 weeks ago         864.9 MB
centos              centos6             b1bd49907d55        5 weeks ago         212.5 MB
centos              centos7             b157b77b1a65        5 weeks ago         243.7 MB
centos              latest              b157b77b1a65        5 weeks ago         243.7 MB

Create the tag:

$ docker tag fe809d275af3 danehans/nodesrv:latest
$ docker images danehans/nodesrv
REPOSITORY          TAG                 IMAGE ID            CREATED             VIRTUAL SIZE
danehans/nodesrv    v1                  fe809d275af3        18 hours ago        864.9 MB
danehans/nodesrv    latest              fe809d275af3        18 hours ago        864.9 MB

Container Ops

Instantiate a Docker container with docker run:

$ docker run -i -t danehans/centos /bin/bash
bash-4.1# exit

List running and exited docker processes with docker ps:

$ docker ps -l
CONTAINER ID  IMAGE                  COMMAND      CREATED         STATUS      NAMES
7c4ef3596fa5  danehans/centos:latest  "/bin/bash"  49 seconds ago  Exited (0)  grave_newton

"Diffing" a Container

Run a Docker image and perform some actions:

$ docker run -i -t --name="add_wget" danehans/centos /bin/bash
bash-4.1# yum install -y wget
bash-4.1# exit

Run a diff on the container after it has run:

$ docker diff add_wget
C /.bash_history
C /etc
A /etc/wgetrc
C /tmp
C /usr
C /usr/bin
A /usr/bin/wget
C /usr/share
C /usr/share/doc
A /usr/share/doc/wget-1.12

Docker Containers as Daemons

Start a container as a detached process with docker run -d:

$ docker run -d danehans/nginx:base
$ docker ps
CONTAINER ID  IMAGE               COMMAND               PORTS   NAMES
1aa9f0bd1418  danehans/nginx:base  "/bin/sh -c '/usr/sb  80/tcp  elegant_bell

Use the -P flag to automatically map container ports to the Docker host:

$ docker run -d -P danehans/nginx:base
$ docker ps
CONTAINER ID  IMAGE               COMMAND               PORTS                  NAMES
1c2e06d8f85e  danehans/nginx:base  "/bin/sh -c '/usr/sb>80/tcp  loving_mclean

Docker Does:

  1. Portability
  2. Workflow
  3. Easy
  4. Speed

Docker Doesn't

  1. See beyond a single host
  2. Provision related containers as a unit
  3. Have capacity for handling mass configuration & deployment.

PaaS Component #2:

Kubernetes Logo

Kuberenetes Terminology

Kubernetes minion diagram  
One or more inter-related Docker containers.
A configuration unit for the kube-proxy.
Used with pods to specify identifying metadata.
Runs cluster-level control plane services.
A Docker host running the kubelet and the proxy service.


Visualization of raft consensus

Minion Daemon:

Kubelet works between etcd and docker.
  • Pod management
  • Take instructions from the cluster master

Minion Daemon:

The proxy maps a single port on the minion to all relevant pods


  • The proxy service maps a common port on every minion to relevant pods across the entire cluster
  • Relevant pods are chosen by comparing a label on the proxy definition to labels on the running pods

Cluster Management

Kubernetes cluster master diagram  
Kubernetes API
RESTful API for Kubernetes
Choose minions for pods
Controller Manager
Monitoring service for deployed pods
CLI for working with a Kubernetes cluster

Kubernetes Doesn't


  • Have a concept of a complete application.
  • Have capacity for building and deploying Docker images from source code.
  • Have a focus on a user or admin experience.

Bringing it All Together:

OpenShift Logo

Applications =
Distinct Interconnected Services

  • Distinct: App components must be abstracted so that they can evolve independently
  • Interconnected: Every component should be easy to build, manage and deploy in concert

Applications in OpenShift 3



config, n.
A collection of objects describing a combination of pods, services, replicationControllers, environment variables.

template, n.
A parameterized version of a config for generalized re-use.

Builds in OpenShift v3


buildConfig, n.
An object containing three key pieces of information about an application that will be automatically built and rebuilt by OpenShift:

  • The source code URI
  • The build type (Docker or STI)
  • The authentication code for change notifications (webhooks)

Application Lifecycle:

Integrating with CI and CD through "triggers"

Make a platform that is aware of changes:

  • In source code
  • On a CI system
  • In an image repository that the entire product lifecycle is
repeatable, fault-tolerant and automated.

Lifecycle in OpenShift 3:

The Deployment

deployment, n.
The combination of:

  • A replicationController that describes a desired running state.
  • One or more trigger policies for driving the deployment
  • A deployment strategy for performing the deployment

Deployment Trigger Policies



Image change

config change

New Concepts Summary


  • Configurations
    • Collections of Kubernetes and OpenShift 3 objects
    • Parameterized templates
    • Post-processed configs
  • Builds
    • Where is the code coming from?
    • How do we turn it into a Docker image?
  • Deployments
    • When do we deploy?
    • How do we deploy?
    • What should the deployment look like?

Enough Talking... Let's See It!

Getting Started


Thank You!



Learn More:



Presented by
Diane Mueller, Red Hat OpenShift / @pythondj
Daneyon Hansen, Cisco / @daneyonhansen