Deploying MongoDB Enterprise with Ansible

I’ve been asked about this subject several times, so I thought it might be best to put some thoughts into a blog post and share it.

For the purposes of this article, I’m going to assume you have ansible installed.  If you need help with that specifically, refer to the site for specific documentation on installation.

Question: Why does your image refer to Opsmanager?  I thought we were going to cover Ansible.

Answer: Opsmanager can accomplish many things over and above what Ansible covers.  Monitoring, Automating, Optimizing and Backing up your MongoDB installation.  I won’t cover Opsmanager in this article but if you’re running MongoDB in production, I highly recommend looking into Opsmanager.

Ansible is an incredible tool.  It’s also been referred to as “SSH Configuration Management on Steroids.”  Explaining what Ansible is and how it works is beyond the scope of this article.  I will however, provide some basic details specific to the application of Ansible around the problem of deploying MongoDB.

Ansible leverages SSH to enable you to manage, and automate the process of configuring and maintaining configuration on a number of servers.


The first thing to know about Ansible is that it requires knowledge of the servers you’ll be managing using the tool.  This knowledge is maintained using an inventory file.

Ansible works against multiple systems in your infrastructure at the same time. It does this by selecting portions of systems listed in Ansible’s inventory file, which defaults to being saved in the location /etc/ansible/hosts. You can specify a different inventory file using the -i <path> option on the command line.

Not only is this inventory configurable, but you can also use multiple inventory files at the same time (explained below) and also pull inventory from dynamic or cloud sources, as described in Dynamic Inventory.  This is a mind-blowing concept for some.  A dynamic inventory is one that can change… it’s not a static file, it’s a script that returns a list of servers.

For the time being, let’s leave the dynamic capability to the side… and let’s create a static file containing the names of the servers on which we’ll install MongoDB.

Where you see “[mongodb]” – this is a group indicator.  It tells Ansible that the next lines will be servers that should be a part of the group indicated… in this case “mongodb”.  The string mongodb is arbitrary and could be anything… “MyServers” would work just as well.  It’s later when we write some Ansible commands that we’ll refer to these servers as a group – and the group name will be important.

Where you see and these are the fully qualified domain names of the servers on which you’ll be installing mongodb.  If you’re installing a replica set – you’ll most likely have three.

As I’m writing this article, I have 3 servers deployed in AWS/EC2 that I’ll be using.  So – here’s what my inventory file looks like:

Server Access and Connectivity

Ok, so now we’ve defined our universe of servers, let’s talk about how we’re going to leverage Ansible to effect change on these servers.  Ansible uses SSH to connect and manage servers.  In order for this to happen, you need to give Ansible the appropriate credentials.

Ansible will assume you have SSH access available to your servers, usually based on SSH-Key.  Because Ansible uses SSH, the server it’s on needs to be able to SSH into the inventory servers. It will attempt to connect as the current user it is being run as.

Getting Busy

Ok, now we understand the servers on which we’ll install MongoDB, as well as the mechanism with which we’ll access and impact change on those servers, let’s get busy and do something.

In its very basic form, Ansible can be used from command line to do things with your server inventory.  The most basic command you can try right now is Ping… Ping sends a UDP packet over the network to those servers and verifies connectivity.

In this simple  example, I’m using the ansible command, specifying the location of my inventory file and calling an ansible command module called ping against a group called “ReplicaSet.”  Ansible responds with the output and results of the command I ran.


Ansible’s nature is to automate things.  So, naturally, you can automate the process of telling Ansible things about your configuration or your environment.  The inventory file, for example – that can be set in your env so you don’t have to use the -i switch each and every time you run a command.

In this way, I’ve now set my inventory file in my environment and I no longer have to use the -i switch.  So I can simply type the following to achieve the same output as previously.

Additionally, where I’m leveraging the -m switch to specify the module I want to use, I can instead, use another command and move the actual work I want accomplished to another file called a playbook.  Ansible playbooks are like scripts that describe the work you want ansible to accomplish.

Playbooks leverage YAML – Yet Another Markup Language.  This is a straight forward, easy to read configuration language.  You’ll get the hang of it quickly.  Here’s an example of the previous ping command represented in Playbook, YAML Format:

And here’s what that looks like when we execute it:

If you’re playing along at home, place the YAML code for the ping command into a file called ping.yml.  Then execute the command ansible-playbook ping.yml.

So ping is awesome but what about mongodb?

Yea – we’re getting there.  I get it, you’re impatient… so am I.  Alright – so where are we?  We know our inventory of mongodb servers… we understand how we’re going to access them via SSH and we just learned about the fact that we can create these awesome script-like things called playbooks.

In the ping example playbook, I used a section called tasks.  Tasks are where we leverage commands that ansible understands to carry out the things we want to accomplish on our inventory of servers… ok – so how then do we install MongoDB?

Ansible does for you what you are not able, or don’t want to do for yourself.  However, it does it in the same manner.  With MongoDB, specifically in the Linux world… the easiest way to install it is by installing a REPO, or an RPM repository and leveraging the YUM command to install the packages for you.

YUM satisfies all dependencies during the installation process so it makes managing your software installations a lot easier.  We could, technically, use Ansible to download the binaries, and perform a manual compile and install… sure.  But let’s leverage the power of package management to do all that for us.

In order to use YUM, we first need to define a repository.  The following is the repo definition for MongoDB Enterprise.

To use this repo without ansible, you’d copy the repo file to each of your servers, then execute yum update, and yum install mongodb-enterprise, etc.

We’re not going to that – we’re going to let Ansible do that for us.  So.  Step 1 will be to create a file called mongodb-enterprise.repo and copy in the contents from above.  Place this file in a directory called files (for neatness, of course.)

Next, let’s create the playbook we’ll use that will refer to this repo.  Here’s what mine looks like:

Let’s break this down.

Line 001: Starter YML
Line 002: Hosts designation – let’s ansble know what hosts we’re acting on.
Line 003: Remote user designation – who are we impersonating when we execute these changes on the remote host.
Line 004: Become – this is the same as sudo, essentially.  We need to make these changes as a super user.
Line 005: Tasks designator – begin block.
Line 006: What file are we using?  We are going to send this file to our remote hosts, one at a time.
Line 007: Once there, what commands will we be executing.  First, let’s do a generic update.  The equivilant of this is “yum update”.
Line 008: Next, we want to target a specific package whose state we want to change… specifically, we want the state of the package named mongodb-enterprise to be installed at the latest version.
Line 009: Now we want to install the mongodb shell commands.
Line 010: We also need gpg installed.
Line 011: Lastly, we’re going to run MongoDB in a specific directory – namely “/data”.

Let’s give it a shot.  First, place these commands in a file called playbook-replicaset-enterprise-prerequisites.yml in a directory called playbooks.

Here’s what this looks like when it runs:

If all goes according to plan, you should end up with MongoDB Enterprise installed on your hosts.

Let’s go interrogate one of the servers to make sure.

Sure enough, MongoDB is installed and ready to go.

So – now that we’ve installed it using a package manager, what about starting, stopping, restarting, etc.?  Ansible can easily accomplish these from command line – but let’s create playbooks so we have them in our arsenal.

Let’s create a new playbook called playbook-replicaset-start.yml and fill it with the following content.  Notice we’re calling mongod directly, and not relying on the service commands… you will want to examine this should you further your deployment into a production environment.

Here’s what our new mongodb start playbook looks like in action:

And now let’s verify that we’ve actually effected the expected change on our servers:

So that’s it folks, we’ve gone from zero to hero with Ansible and MongoDB.  To recap, we learned about Ansible’s inventory.  We learned how to run ansible from the command line as well as how to create scripts called playbooks.  We created a repo file, distributed that to our servers and leveraged that via ansible to install mongodb.

If this topic interests you and you’re looking to go to the next step, check out my repository on github that contains some great playbook content – some of which I wrote and a lot of which my colleague Torsten Spindler wrote.  This repo enables you to automate the process of installing MongoDB and leverages Opsmanager – registering newly installed hosts with the opsmanager console.  This will better prepare you to manage your production implementation of MongoDB.

This is just a beginning, but I hope you can see the incredible power and flexibility that Ansible can bring you.  Feel free to leave a comment or question should you have either.

You may also want to review the scripts I’ve created as a part of this post.  They can be found and freely downloaded at:

Leave a Reply

Your email address will not be published. Required fields are marked *