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

Why IaaS is not on Enough
What is PaaS
Deploying OpenShift on OpenStack today
OpenShift V2 with Heat
Witty One-Liners

Docker Overview
Kubernetes Overview
OpenShift 3 Overview
Deploying OpenShift V3 Demo
Links to all the Cool Stuff on GitHub and Docker Hub

Important Stuff

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

Assumptions

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

Infrastructure-as-a-Service
is Not Enough

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

Software-as-a-Service

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

SalesForce.com, Google Apps, iCloud

Platform-as-a-Service

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

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
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
1aa9f0bd1418f951a590c12ad717ea8af639dd29969ee3f59dfd87da1da23c4e
$ 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
1c2e06d8f85e6e034dfd1f7e822b32ed3f4ddf1d5760011d1e84a88a589f50f3
$ docker ps
CONTAINER ID  IMAGE               COMMAND               PORTS                  NAMES
1c2e06d8f85e  danehans/nginx:base  "/bin/sh -c '/usr/sb  0.0.0.0:49153->80/tcp  loving_mclean

Docker Does:

Portability
Workflow
Easy
Speed

Docker Doesn't

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

The entire docker lab could be done with a single host instance. That's a by-product of Docker's chief limitation as a host-centric technology. This wasn't an oversight as much as a scope boundary.

Even within the single-host scope, Docker doesn't provide for managing related containers as a group. If you want to run a web server container alongside a database container, you have to do them one at a time.

Another problem related to the host-level focus is that Docker itself doesn't have any sort of mass provisioning for containers. This includes configuration, deployment, and ongoing management.

To Docker's credit, they have specifically determined that this stuff is out of scope for their project. However, it left a big opening for technologies to come along and solve. Solution? Kubernetes.

PaaS Component #2:

Kubernetes

Kuberenetes Terminology

Pod:: One or more inter-related Docker containers.
Service:: A configuration unit for the kube-proxy.
Label:: Used with pods to specify identifying metadata.
Master:: Runs cluster-level control plane services.
Minion/Node:: A Docker host running the kubelet and the proxy service.

etcd

Minion Daemon:
`kubelet`

Pod management
Take instructions from the cluster master

Now, the other minion-based process is called kubelet. Its main job is pod management, which really means that its main job is talking to docker. The kubelete daemon interprets pod definitions in docker terms and makes the right commands to get the desired behavior. All docker functionality is available through kubelet and pods.

In addition to managing docker, the kubelet has another job, which is to keep track of pod running states. The kubelet is periodically polled by cluster management processes to know how the cluster is doing.

Finally, another feature of the kubelet that is in the works is the ability for the kubelet to register its minion with the cluster. Right now minions have to be introduced manually, but when this feature is in place, a kubelet with the right credentials can join a cluster automatically.

Minion Daemon:
`kube-proxy`

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

The interesting thing about the service proxy is that every minion gets all of the service proxy rules, regardless of which pods are actually running on the them. The job of the proxy starts with the question: "does this minion have any pods that match each of the service labels that I know about?"

In this diagram, the proxy knows about three services. But looking over the pods that are running, the proxy sees that it can't handle requests for the mongo service. On the other hand, it's got two running pods that match the 'nginx' label, so it will handle the routing and traffic management to those pods.

The proxy service is not responsible for managing pods. All it does is indicates whether or not the minion can handle a given service request, and if there's more than one pod that can satisfy the request, it does the traffic management.

Cluster Management

Kubernetes API: RESTful API for Kubernetes
Scheduler: Choose minions for pods
Controller Manager: Monitoring service for deployed pods
kubecfg: 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:

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

...so 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

Manual

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

Questions?

Thank You!

Learn More:

Docker: docker.com
Kubernetes: github.com/GoogleCloudPlatform/kubernetes
OpenShift 3: github.com/openshift/origin

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

OpenShift on OpenStack

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

Today's Agenda

Important Stuff

Assumptions

Part 1: PaaS On OpenStack?

Cloud Services

Why Put a PaaS on OpenStack?

Infrastructure-as-a-Serviceis Not Enough

Software-as-a-Service

Platform-as-a-Service

The 3 Flavors of OpenShift

What can you do with OpenShift?

How Does It Work?

How Does It Work?

Heat: Putting the PaaS in OpenStack

Cross Community Collaboration

Heat Overview

OpenShift Origin Heat Templates

OpenShift Enterprise Heat Templates

Watch it at your leisure here on YouTube

So Why a New PaaS?

First PaaS Component: Docker

What is a Container?

Images: More like git than tar

Versioning / Tagging

Container Ops

"Diffing" a Container

Docker Containers as Daemons

Docker Does:

Docker Doesn't

PaaS Component #2:

Kubernetes

Kuberenetes Terminology

etcd

Minion Daemon:kubelet

Minion Daemon:kube-proxy

Cluster Management

Kubernetes Doesn't

Bringing it All Together:

Applications =Distinct Interconnected Services

Applications in OpenShift 3

Builds in OpenShift v3

Application Lifecycle:

Integrating with CI and CD through "triggers"

Lifecycle in OpenShift 3:

The Deployment

Deployment Trigger Policies

New Concepts Summary

Enough Talking... Let's See It!

Getting Started

Questions?

Thank You!

Infrastructure-as-a-Service
is Not Enough

Images: More like `git` than `tar`

Minion Daemon:
`kubelet`

Minion Daemon:
`kube-proxy`

Applications =
Distinct Interconnected Services