Maish Saidel-Keesing & Naama Bamberger, Cisco - The OpenStack Plugin for Jenkins, OpenStack Israel 2015
•Download as PPTX, PDF•
0 likes•593 views
Maish Saidel-Keesing & Naama Bamberger, Cisco - The OpenStack Plugin for Jenkins, OpenStack Israel 2015
Recommended
Recommended
More Related Content
What's hot
What's hot (15)
Viewers also liked
Similar to Maish Saidel-Keesing & Naama Bamberger, Cisco - The OpenStack Plugin for Jenkins, OpenStack Israel 2015
Similar to Maish Saidel-Keesing & Naama Bamberger, Cisco - The OpenStack Plugin for Jenkins, OpenStack Israel 2015 (20)
More from Cloud Native Day Tel Aviv
More from Cloud Native Day Tel Aviv (20)
Recently uploaded
Recently uploaded (20)
Maish Saidel-Keesing & Naama Bamberger, Cisco - The OpenStack Plugin for Jenkins, OpenStack Israel 2015
- 1. Simple and Painless CI/CD The OpenStack Plugin for Jenkins Naama Bamberger (nabamber@cisco.com) Maish Saidel-Keesing (msaidelk@cisco.com) Monday, June 15, 2015
- 2. Nice to Meet You! Integrated Infrastructure Adiel Grosmark (agrosmar@cisco.com) Einav Rivni (erivni@cisco.com) @maishsk
- 3. Learn more about Cisco’s technology and solutions for OpenStack®, in three areas: BuildingOpenStack CodeContributions Infrastructure UsingOpenStack Operations and Management Application Tools ConnectingOpenStack Intercloud PartnerEcosystem
- 6. Our Goal? A CI/CD pipeline – using OpenStack
- 8. Modular Stack ardonik (flickr) • Modularity • Each team is responsible for their components • Heat defines only the deployment model ardonik (flickr)
- 9. Doesn’t this complicate things? dannyman (flickr)
- 10. That is where Jenkins comes in
- 11. The plugin
- 13. • Required RPMs • Dependent products • HEAT template • Puppet scripts Define Product Generate Product Artifact Define Deployment Deploy on OpenStack
- 14. Define Product Generate Product Artifact Define Deployment Deploy on OpenStack • Resolve versions • Download dependencies • Generate Artifacts (pom, tar, rpm) • Upload to Nexus
- 15. Define Product Generate Product Artifact Define Deployment Deploy on OpenStack • What to deploy? • Where to deploy to? • OpenStack credentials • Stack parameters • Which YUM repo to use?
- 16. • Delete old stack • Download all artifacts • Move RPMs to YUM repo • Load stack • Set parameters • Create Stack • Wait for completion Define Product Generate Product Artifact Define Deployment Deploy on OpenStack
- 17. • From cloned Heat git repo • Load stack by name pattern (xx.yaml, xx.env.yaml, xx.yaml.dependencies nested files) • Parse yaml & replace parameters (Jenkins) • Generate the createStack REST request from the loaded data Stack Creation
- 18. • For multiple stacks, with relationships and dependencies • Database (backend) • Web application • In the ‘product create’ step, you can set the dependent products and the order in which they will be deployed • The Jenkins plugin will deploy the whole set Nesting tambako (flickr)
- 19. • Input and Output parameters Wiring output input1 2
- 20. Demo Time!!
- 21. • https://github.com/foundation-runtime/jenkins-openstack-deployment- plugin • https://github.com/ciscosystems Links and Info
- 22. Thank You
Editor's Notes
- Cisco’s engagement in OpenStack is broad and we have 30 presentations at the Summit to share the details of what we’re working on. We are using three simple categories to describe our work: We are helping organizations BUILD OpenStack, USE AND OPERATE OpenStack, and CONNECT OpenStack cloud applications and services—all in order to support innovation and growth. There are multiple sessions in each of these areas. Please ask any of the Cisco employees here at the conference for more information if you have questions. My presentation today addresses….., which is part of how we are helping BUILD (or OPERATE, or CONNECT)…
- Want to test on a OS env as early as possible With full deployment – including HA Minimal Viable product not for scaling and performance purposes.
- Components RPMs which change daily Coming from multiple teams in multiple geographical locations and timezones Deployment code and model for each component OpenStack environments There is a tight coupling between the different components and a decent amount of wiring required to get them working Stack parameters to support multiple permutations
- CI/CD pipeline which gets the artifacts build from latest code deploy it on OpenStack with a full ecosystem a minimal viable deployment model run tests against new deployment push artifacts to next stage if test succeed
- Components are applications – RPM’s and dependencies. Product – Collection of application that are logically connected Solution – a set of products that are delivered to the end customer Deployment script saved with component RPM In binary repository repo Component development team is responsible for generating deploy scripts for their component HEAT defines only model
- Deployment script saved with component RPM In binary repository repo Component development team is responsible for generating deploy scripts for their component HEAT defines only model
- Build the deployment packages on the fly and the Heat template only describes the deployment, and all application specific logic resides with the components themselves.
- Combines the pieces Packaging Connecting with Nexus and Openstack And keeping the element you have to take care of at a minimal level We use Git and Nexus – you can own support for whatever you want – we will be adding Artifactory in the near future.
- Stack loading: From cloned heat git repo Load stack by name pattern (xx.yaml, xx.env.yaml, xx.yaml.dependencies nested files) Parse yaml Replace parameters using key names Generate the createStack REST body from the loaded data
- Sometimes you have multiple stacks, when one relies on the other For example: a stack deploying a database, and a stack that uses it. In the ‘product create’ step, you can set the dependent product similar to the way you define dependent components The Jenkins plugin will deploy both
- We still need to tie the stacks From the previous example – use the IP (or LB DNS name) of the database to configure the next stack using it. We do that by using the stack’s input and output parameters Matching is done by key names, in output/input parameters Output parameters of prev stack can appear as input parameter of the next In the DB example – the DB stack will publish an output parameter (db-dns) with the value generated by the stack The next stack will expect an input parameter with the same name Jenkins will collect output params, try to match them in subsequent stacks, and set the values when found