How to Automate MongoDB Deployments Using Ops Manager/Cloud Manager

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.

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. 

As you can see, using Ops Manager/Cloud Manager to automate MongoDB deployments is a fairly simple process, but if you get stuck along the way, there’s no need to worry. MongoDB has an extensive knowledge base and provides documentation for every product they offer. They also offer free courses on MongoDB University that will not only help you get up to speed quickly and at your own pace, but it also looks pretty good on your LinkedIn page or resume. I highly recommend starting with M102: MongoDB for DBAs. It's a fantastic introduction and will give you all the information you need to administer a MongoDB installation in production. 

Additional Resources

As a side note, for DBAs needing to get data from legacy systems into MongoDB, I recently published a post detailing my experience using Oracle Golden Gate for big data to replicate data to MongoDB. For those just considering MongoDB, perhaps alongside Cassandra and Oracle, make sure to check out my post on why we went with MongoDB, and if you have any questions or just want to talk databases, feel free to reach out to me on Twitter: @mikegray831.