OpenShift DevOps: From Origin to Online
•Als ODP, PDF herunterladen•
7 gefällt mir•3,441 views
DevOps @ OpenShift Online Presenter: Adam Miller As the Release Engineer and a member of Operations team for OpenShift Online, a downstream consumer of OpenShift Origin and the largest Public implementation of OpenShift to date, Adam Miller will discuss what it's like behind the scenes at OpenShift.com and share lessons learned and bring his thoughts and feedback on the future direction of Origin.
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Andere mochten auch
Andere mochten auch (20)
Ähnlich wie OpenShift DevOps: From Origin to Online
Ähnlich wie OpenShift DevOps: From Origin to Online (20)
Mehr von OpenShift Origin
Mehr von OpenShift Origin (19)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
OpenShift DevOps: From Origin to Online
- 1. OpenShift DevOps From Origin to Online Adam Miller OpenShift Release Engineer 1 by
- 2. 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. 2 by
- 3. 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? 3 by
- 4. The Flow of Code Open Source Project origin On-premise Public or Private Cloud Cloud Service Software 4 by
- 5. OpenShift Architecture – Contents of a DevEnv 5 by
- 6. How Jenkins Orchestrates DevEnv Creation Register Image with EC2 to launch instances to build DevEnvs in Jenkins Base AMI Clean OS Image (RHEL/Fedora) used to build on Jenkins top of. Register Image with Development EC2 to launch Environments DevEnvs 6 by
- 7. How DenEnvs are Built Use Base AMI to build new devenv Launch instance of latest Base AMI Base AMI Jenkins Report Test results, register DevEnv AMI Sync code to devenv, build clone master branch rpms from source. API Calls Code OpenShift Origin Test Results 7 by
- 8. How Development Happens Sync code DevEnv Code (Local branch Run Cucumber and rake from GitHub) tests, get output Pull Request DevEnv Jenkins OpenShift Origin OpenShift-bot 8 by
- 9. How Deployment Works in OpenShift Online Integration: Staging: Production: Daily deployment Release Candidate Production Code from RPM package code deployed here deployed here, sets. for final round of QA OpenShift.com and sign off. Code stage OpenShift Origin Master branch (where continued development happens) 9 by
- 10. What The Environments Look like REST API REST API DNS DNS Load Balancers SSO SSO Brokers Nodes ActiveMQ 10 by
- 11. Thank You. Questions? Adam Miller admiller@redhat.com 11 by
Hinweis der Redaktion
- 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.
- 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. <Click for next slide>
- 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. <next slide>
- A DevEnv is a self contained single instance of OpenShift used for testing and development of the platform.. <next slide>
- 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. <next slide>
- 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). <next slide>
- 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. <next slide>
- 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.
- 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 very much for your time today. I’m happy to take any final questions that you may have. <end>