How to Automate MongoDB Deployments Using Ops Manager/Cloud Manager

Upshot
Upshot by Influitive
3 min readMay 16, 2018

--

by Michael Grayson, Senior Oracle/MongoDB/MySQL Database Administrator at Paychex

MongoDB makes automated deployments a breeze. Get up and running today using this simple how-to guide, and ensure your automated deployments go off without a hitch.

In today’s decentralized, cloud-based environment, being able to automate continuous deployments is a must, and while it’s usually rather easy and not incredibly error prone to use Ops Manager/Cloud Manager to automate MongoDB deployments, there are a few points where we can get tangled up. So to help other database administrators ensure their automated deployments go off without a hitch, I thought I’d share a few tips and tricks to make the process go smoothly.

For cloud and on-premises environments, there’s no need to have MongoDB installed, simply start with your base OS image. However, if you’re running Linux you will need to have the corresponding .rpm packages. Once you’re ready to begin, start with the automation agent.

For Linux users, running the correct .rpm packages for your MongoDB deployments is a must.

Where to begin: Laying down an automation agent.

This process can be automated, so that it comes with the build, or it can be automated into the build process itself. That way when your server is being built, it calls out to Ops Manager and grabs the latest automation agent. With the automation agent in place, that’s when the automated process can begin to lay down either a standalone replica set or part of a sharded cluster.

My recommendation is to have this as part of the actual build process so you’ll be able to hand off to DBA pretty much already built. If you’re using the Waterfall method, you’ll have to move from SA to storage to DBA, which is incredibly time consuming. Whereas by having your storage added automatically, SA does their build and has their process include callouts from Ops Manager and you can hand off to DBA pretty much already built.

Choosing the right automation tool.

This decision all comes down to use case. It’s important to choose the right tool for the job. For my team , we use Puppet to make calls to the Ops Manager API; however, many teams like Chef.

Puppet’s long track record and its use in some of the largest and most demanding environments made it the right choice for us. But for those looking for an open source tool geared more for the developer crowd, check out Chef. Both are based in Ruby, but Puppet uses a customized Domain Scripting Language (DSL) closer to JSON. Another thing to note is that Puppet uses a model-driven approach and runs as a master-client setup, and the code design works as a list of dependencies that, depending on your setup, can make things easier or more confusing…

Read the full story here.

--

--