Building Clouds with OpenStack Puppet Modules

The OpenStack Puppet project provides Puppet modules for deploying each of the OpenStack services. Find out how to deploy clouds using these modules, as well as tips for contributing patches and participating in the OpenStack Puppet community. The majority of this talk will be a discussion of real world experiences from Time Warner Cable and Go Daddy.

Transcript

1. Building Clouds with OpenStack Puppet Modules Mike Dorman, Matt Fischer, Emilien Macchi Slides: http://x.co/9NJxu
2. Who We Are • Mike Dorman - Senior Systems Engineer at Go Daddy ◦ mdorman@godaddy.com / @misterdorm • Matt Fischer - Principal Engineer at Time Warner Cable ◦ matt.fischer@twcable.com / @openmfisch • Emilien Macchi - Puppet OpenStack PTL ◦ emilien@redhat.com / @EmilienMacchi
3. What is Openstack Puppet?
4. Modules Know OpenStack Services
5. … But We Don’t Cook For You. • Compose your high level module • Use Hiera for data-driven deployment
6. How to Use the Modules • OpenStack Installer ◦ Compose the manifests for you ◦ Less flexibility but easier to deploy • Custom Puppet composition ◦ More difficult, require good Puppet skills ◦ But more flexible, allow complex deployments
7. Installers That Use Our Modules • Packstack • Staypuft • RDO Director • Mirantis Fuel • SpinalStack • ...
8. Custom Puppet Composition • Requires good understanding of Puppet • Puppet master vs masterless • Hiera vs Non-Hiera • Theoretically no limits
9. http://superuser.openstack.org/articles/openstack-users-share-how-their-deployments-stack-up
11. OpenStack Use Case • Internal only private cloud • Efficiencies and innovation ◦ Self-service ◦ Eliminate tickets & humans clicking buttons ◦ Faster POCs/time to market ◦ Better hardware utilization • Leverage power of the community and OSS • Multiple DCs & Regions
12. Why Puppet? • Go Daddy is a big Puppet user • Drives most of our product environments • “The best configuration management system is the one you’re already using.” • Modules for core OS services are mature & well-supported • Already building our own composition layer
13. Composition Layer • Role/profile model ◦ meta app, cell app, pod, compute roles • Hiera + hiera-eyaml for data ◦ Roles defined in hiera • Handles 100% of server configuration ◦ Not only OpenStack-specific pieces • Differentiate between dev/test/prod “worlds” • Extensive use of “future parser” (Puppet 4.x)
14. site.pp role/manifests/init.pp hiera.yaml
15. Modules • OS modules: ceilometer, cinder, glance, heat, horizon, keystone, neutron, nova, openstacklib • ~25 other modules from PuppetForge • 4 custom modules for internal systems • Internal GitHub ◦ Pull from upstream as needed
16. Deploying • Masterless Puppet • Manifests & modules git cloned via r10k • Ansible kicks off Puppet runs • Working toward CI/CD/Jenkins integration
17. Best Practices • Don’t fork • Don’t fork! • Really, don’t fork! • If you must: use a local branch and submit to upstream project
18. Best Practices • Keep composition module simple ◦ Data bindings with hiera ▪ https://docs.puppetlabs.com/hiera/1/puppet.html#automatic-parameter-lookup ▪ https://puppetlabs.com/presentations/data-bindings-puppet-3-puppet-forge ◦ More granular profile classes ◦ Avoid conditionals • Shouldn’t have to run Puppet multiple times ◦ But this can be tough to achieve
20. OpenStack Use Case • Multi-Data Center Private Cloud • Speed, self-service, and innovation were the main driving factors for using OpenStack ◦ No more waiting weeks for a VM or IP ◦ Easy to add-on services like Designate or LBaaS ◦ It gets better every cycle
21. Why Puppet? • Previous TWC experience with Puppet • OpenStack Puppet use began with Cisco Puppet Openstack Builder • We did not want to use an OpenStack distro • Active & friendly community
22. Composition Layer • Roles/profiles & hiera to configure our nodes • Handles all configuration • Composition layer defines architecture • This module has grown large and complex
23. Applying Roles & Hiera yvr01-keystone-002 keystone 002 Hostname Site/Iteration Role Instance Echelon prod yvr01
24. Other Modules • Using over 70 modules total ◦ local github and github.com • Custom modules ◦ Icinga Module ◦ haproxy Composition Module ◦ Infra Module ◦ Keystone Module
25. Deploying • Managed by Jenkins • Orchestrated by Ansible • Deployed by r10k • Driven by Puppet
26. Best Practices • Use Hiera to separate config and code ◦ Use hiera data bindings! • Use eyaml to protect secrets • Code reviews • Have regular and frequent deployments • Participate in the community!
27. Recommendations and Challenges
28. Recommendations • Code/data separation with hiera • Role/profile model for node classification • External orchestration (Ansible) • Protect the secrets • Deploy small changes often • Plan on iterating your workflow
29. Challenges • Master vs stable branches • Managing local repos & upstream pulls • Keeping up with module changes • Finding people with both Puppet and OpenStack skills is difficult
30. Working With The Community
31. Benefits • Feedback from other deployers • Take advantage of the work of others • Provide input on the project • Extensive gate testing • Involvement in OpenStack community
32. How We Work Together
33. The Contributions We Love!
34. The Contributions We Avoid...
35. Future • Moved under “big tent” • More contributors • More consistency with OpenStack • More functional testing in OS infra = more adoption
36. Join Us mdorman@godaddy.com matt.fischer@twcable.com emilien@redhat.com @misterdorm @openmfisch @EmilienMacchi http://x.co/9NJxu