MongoDB World 2018: Using Puppet, Ansible and Ops Manager to Create Your Own On-Premise MongoDB as a Service
•Download as PPTX, PDF•
3 likes•485 views
Using Puppet, Ansible, and Ops Manager, Paychex automated the provisioning of MongoDB databases to address the challenges of a manual process that took 1-2 weeks. Puppet is used for OS configuration and standardization. Ansible is used for orchestration to make API calls to Ops Manager for database provisioning in 15-25 minutes. Ops Manager provides management, automation, monitoring, and backups. Future work includes further integrating backups and restores using Ansible and integrating with additional tools like ServiceNow.
Recommended
Recommended
More Related Content
What's hot
What's hot (18)
Similar to MongoDB World 2018: Using Puppet, Ansible and Ops Manager to Create Your Own On-Premise MongoDB as a Service
Similar to MongoDB World 2018: Using Puppet, Ansible and Ops Manager to Create Your Own On-Premise MongoDB as a Service (20)
More from MongoDB
More from MongoDB (20)
Recently uploaded
Recently uploaded (20)
MongoDB World 2018: Using Puppet, Ansible and Ops Manager to Create Your Own On-Premise MongoDB as a Service
- 1. Using Puppet, Ansible and Ops Manager to Create Your Own MongoDB As a Service Mike Grayson, Paychex MongoDB World ‘18
- 2. Agenda • About Paychex • The Challenge • About Me • How We attacked it • Next Steps 2
- 3. About Paychex Paychex is a leading provider of integrated human capital management solutions for payroll, HR, retirement, and insurance services. Backed by 46 years of industry expertise, Paychex serves approximately 605,000 payroll client as of May 31, 2017, across more then 100 locations and pays one out of every 12 American private sector employees. 3
- 4. About The Paychex Environment 4 IT Operations – Data Services • Operations • Applications • Platform • 3 data centers, 2 regions • Multiple database and data platforms supported • 100+ applications supported Database Footprint • ~35,000 databases • ~1500 VMs • ~250 physical hosts • ~100 MongoDB databases
- 5. The Challenge – IT Edition • More and more requests for MongoDB Infrastructure • Partially automated build • Build more and keep things: • Standard, Easy for Operations, Monitored, Low Risk 5
- 6. The Challenge – Business Edition
- 7. The Challenge – Business Edition Cont’d
- 8. The Challenge – Business Edition Cont’d
- 9. Manual Flow • End to End Time: 1-2 weeks!
- 10. The Manual Way • Development sends in a ticket requesting DB • Database Engineer reviews Solutions Architecture with Solutions Leads • Database Engineer requests VM(s) from Systems Team • VM(s) Provisioned by Systems Team • Database(s) built, users added, custom roles added, Monitoring, Backups, etc. setup • Turn Around Time 1-2 weeks, MongoDB SME (me) involved in just about every build
- 11. About Me • Using MongoDB for about 4 years • MongoDB Master 2016-present • Twitter: @mikegray831 • Blog: https://mongomike.wordpress.com/blog • I don’t scale! 11
- 12. If at first you don’t succeed…. Putting all the automation logic in Puppet
- 13. …try, try again Putting all the automation logic in Ansible
- 14. Problems remain • Upgrades still manual • Brittle Solutions • Integrations remain manual • Engineer Apathy “It’s still faster than Oracle builds”
- 15. Solution • MongoDB as a Service • However: • Different applications have different requirements and even different replica set design patterns • No standard way of building MongoDBaaS 15
- 17. Automation Flow End to End Time: 15-25 minutes depending on Replica Set size
- 18. What is Puppet? • configuration management tool • manage your systems declaratively with a Ruby-like language, “Infrastructure as Code” • create manifests that can be pushed to many hosts via declared host groups 18
- 19. When We Use Puppet • Configuration management • Making sure a service is always “up” • Keep hosts within a group of hosts using the same configuration 19
- 20. When We Don’t Use Puppet 20 • When Orchestration is needed • Managing Database RPMs
- 21. How we use Puppet • OS Configuration • Disable Transparent Huge Pages (THP) • Create the mongod user • Create data mounts with correct permissions • Ops Manager Automation Agent Install 21
- 23. Puppet Code Samples Cont’d 23
- 24. What is Ansible? • Automation for everyone • Devops made simple • Agentless 24
- 25. When We Use Ansible • When order matters • When a process needs to occur once, and only once • With immutable server architecture (create, destroy, replace with no interruption) • Integrations needed 25
- 26. How We Use Ansible • API Call to Ops Manager to build MongoDB 26
- 28. Ansible Code Examples Cont’d 28
- 29. Ansible Code Examples Cont’d 29
- 30. What is MongoDB Ops Manager 30 • Best Way to run MongoDB • Management • Automation Enabler
- 31. When We Use Ops Manager • Provisioning • Monitoring • Backups 31
- 32. How We Use Ops Manager 32 • Add Databases • Setup Backups • Create Users/Roles • Upgrades
- 33. Tying it all together with Orchestration
- 34. Orchestration Options We Considered • Ansible Tower • BMC Atrium Orchestrator 34
- 35. What We Plan To Use For Orchestration • Ansible – AWX (Open Source Ansible Tower) 35
- 36. Future • Use Ansible to setup backups and snapshot schedules in Ops Manager • Use Ansible to automate Ops Manager Restore Jobs • Service Now Integration with AWX • OpenShift/OpenStack Integration • Public Cloud Integration 36
- 37. Lessons Learned • Use the right tool or tools for the job! • There’s always room for improvement • Make the process truly DevOps, involve Development early and often
- 38. Summary • Automation is an iterative process • Work with the business and development to become a business enabler • Get creative!
- 39. Questions? 39
Editor's Notes
- Mention Data Center configuration, 3 data centers, 2 regions
- Why was the build partially automated, what challenges did we face? Increase # of databases per engineer
- If systems fail, people don’t get paid, your taxes don’t get sent to the IRS, your 401k changes won’t get sent.
- Talk through time to market challenges, #2 in Payroll and trying to close gap
- Convey that if one part was done incorrectly or a step missed, delays could cause further delays Rife with potential for human errors New project (TNG) required entire app stack, including infrastructure, to be completely automated You can’t scale me!
- MongoDB Advocacy Hub, Beta Tester
- Why did this fail? What did we learn?
- Why did this fail? What did we learn?
- Upgrades had to be done via YUM repositories
- What are some of the different requirements Azure Arbiter, secondary reads in region
- Ticket > Solutions Architecture Review > Flow > Test Out
- Whare are some successes we’ve had with these specific points
- Why did we choose not to use Puppet for these, what lessons did we learn to come to these conclusions Database RPMs stored in YUM repo, sync’ed from MongoDB’s repo
- Explain what this code accomplishes
- Explain what this code accomplishes
- Why is Ansible easier to learn How does it makes Devops simple? (Same language as Dev, etc.) What are the benefits of Agentless Architecture (Security Vulnerabilities, etc.)
- Why do we use Ansible for the above We don’t use Ansible for Config Management, because Puppet is better at it, explain why
- What does this code do? (calls to Ops Manager API to start build process)
- What does this code do? (calls to Ops Manager API to start build process)
- What does this code do? (calls to Ops Manager API to start build process)
- Why was Ops Manager a better choice for these then Ansible or Puppet?
- Speak on the importance of orchestration
- Why did we pick these two (existing relationships) What was our evaluation criteria
- Why did we choose open source Tower
- Why are these important to us