PowerPoint Presentation

OpenShift DevOpsFrom Origin to Online

Adam Miller

OpenShift Release Engineer

From Origin to Online

In this session we're going to discuss:- How OpenShift Online consumes Origin- How OpenShift Online contributes to Origin- How code goes from development environments to production.

From OpenShift Origin to OpenShift Online, we will discuss the processes and environments used to make this all possible. We will show how OpenShift Online consumed OpenShift Origin to offer the hosted Online version that users can utilize for free in the cloud. We will also talk about how OpenShift Online contributes back to OpenShift Origin as the main contributor to Origin. Finally, and for a large portion of the presentation we will be talking about how all this comes together in a walk through of the environments used for OpenShift Online DevOps as well as the process by which we bring code to production.

What is DevOps?

a software development method that stresses communication, collaboration and integration between Dev and Ops (paraphrased from Wikipedia)

Devs Op and Ops Dev ... see what they did there?

Effectively this means that the Dev Team and Ops Team work hand in hand instead of being disjoint teams who's only interaction is post software release.

The Flow of Code

origin

Public Cloud Service

On-premise or Private Cloud Software

Open Source Project

OpenShift Origin is the upstream location of code and is where rapid development happens. Both OpenShift Enterprise and OpenShift Online pull from the Origin Code base and any changes that make their way into either the OpenShift Online or Enterprise code base must hit upstream first or in parallel. OpenShift Online follows Origin much more closely than Enterprise as Enterprise gets the full treatment of fit and finish to become a stable code base in which to deliver as a product to customers.

OpenShift Architecture Contents of a DevEnv

A DevEnv is a self contained single instance of OpenShift used for testing and development of the platform..

How Jenkins Orchestrates DevEnv Creation

Jenkins

DevelopmentEnvironments

Base AMI

Clean OS Image (RHEL/Fedora) used to build on top of.

Register Image with EC2 to launch instances to build DevEnvs in Jenkins

Register Image with EC2 to launch DevEnvs

Jenkins is used to orchestrate the creation of a development environment. We create a base AMI at certain intervals so that the image that is used to create the DevEnv AMI is always kept up to date with the latest OS updates. From there a Devenv is launched and code is either pulled from master on git or from an rpm package set in our internal rpm build environment in order to simulate a deployment. Once DevEnvs are created they are registered as AMIs that instances can be launched from for DevOps and QA team members to work with, code, test, etc.

How DenEnvs are Built

Jenkins

Base AMI

API CallsCode Test Results

clone master branch

Launch instance of latest Base AMI

Use Base AMI to build new devenv

Sync code to devenv, build rpms from source.

Report Test results, register DevEnv AMI

OpenShift Origin

In order for a DevEnv to be created, it must be built either from the latest set of code out on master from GitHub or from a rpm package set, then it runs through a series of Cucumber and Rake test cases. In the event the image passes, it becomes registered as the new DevEnv AMI which devs can launch to work off of. The normal process is to build from master on GitHub, this happens many times a day and the process is that a merge task in Jenkins from the OpenShift-bot for GitHub will schedule a build, Jenkins will clone from master, launch an instance of our BaseAMI, sync the github repos to the DevEnv as well as automate laying out the files in a structure that the test case scripts need them in, build the RPMs from source, perform an installation and configuration of OpenShift from the RPM set, and run the test cases (reporting the results back to jenkins along with log collection and archival on Jenkins for the previous 50 builds).

How Development Happens

Jenkins

DevEnv

Code (Local branch from GitHub)

Sync code

Run Cucumber and rake tests, get output

Pull Request

OpenShift-bot

DevEnv

OpenShift Origin

The way code makes it from developers into master is that they will fork Origin's master code base, set Origin to the git upstream origin code repository, spawn a devenv, code in their local git repo, commit code and run the origin-dev-tools utils to sync that code to the DevEnv which will spawn the RPM builds and installation, then using those origin-dev-tools utils can run the test suite. Once a change, patch, or feature has passed the test cases it can then be put into a pull request in GitHub, it should be reviewed by another OpenShift developer and receive a +1 in the comments of the pull then someone with permissions will place a [merge] tag in the comments and the OpenShift-bot will start running a set suite on it. The bot will clone master, pull down the patch from the pull request and merge it locally, then spawn a DevEnv and sync this newly merged code to it (remember the sync will build the RPM package set, and run the test cases. Once the test cases pass, the bot will merge the pull request into the master branch.

How Deployment Works in OpenShift Online

Staging:Release Candidate code deployed here for final round of QA and sign off.

Integration:Daily deployment from RPM package sets.

Production:Production Code deployed here, OpenShift.com

OpenShift Origin

Master branch (where continued development happens)

stage

Code

OpenShift Online DevOps Code graduates from INT to STG and from STG to PROD as a set of RPM packages. Meanwhile on GitHub, development of upstream never stops and no code is allowed into Online that has not been pushed upstream first. Patches to stage are either pushed into master or are pushed to master first and brought from master to stage but upstream of code ALWAYS happens. All environments are currently managed by puppet configuration managment.

What The Environments Look like

Brokers

Nodes

ActiveMQ

Load Balancers

DNSREST API

SSO

Each of the three environments (INT, STG, PROD) all share a like architecture that mirrors what you see here in the diagram, the scale of each environment is of course different as the INT and STG load are far less than that of PROD but we do duplicate redundancy through out the architecture so that we can test as closely in a 1:1 scenario as possible.

Thank You.

Questions?

Adam Milleradmiller@redhat.com

Thank you very much for your time today. Im happy to take any final questions that you may have.

by