devops @ openshift online
TRANSCRIPT
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 [email protected]
Thank you very much for your time today. Im happy to take any final questions that you may have.
by