Evaluating the MongoDB Community Ansible Collection

This entry takes a high-level look at Ansible’s built-in support for provisioning and managing MongoDB. Versions of Ansible 2.9 and above support collections, which allow Ansible modules (and other objects) to be updated and versioned separately from the main Ansible release. The few modules for MongoDB that had been maintained with the Ansible distribution have been moved into a separate community.mongodb repository and expanded to include several more modules. Collections can be independently versioned using Ansible Galaxy, and the latest version at this writing is 1.2.1.

Ansible Modules Coverage of MongoDB Functionality

A quick scan of the documentation shows the MongoDB collection is not a full provisioning solution. Rather, it appears to be meant to build on top of and manage pre-existing MongoDB installations and configurations at various levels.

To begin mapping what is available in the collection, we might break down the existing modules in the collection as follows:

• Main MongoDB components
  • mongodb_replicaset
  • mongodb_shard
  • mongodb_balancer
• Gathering information
  • mongodb_info (instance level)
  • mongodb_status (replica set level)
• MongoDB operation (affect running instance)
  • mongodb_maintenance
  • mongodb_shutdown
  • mongodb_stepdown
  • mongodb_parameter
• MongoDB objects
  • mongodb_index
  • mongodb_user
  • mongodb_oplog (resize)
• Generic
  • mongodb_shell (not idempotent)

To use the mongodb_replicaset module, the following missing pieces are required or probably needed for practical usage:

1. MongoDB software installation on the server(s)
2. Running MongoDB instances, with mongod.conf files
3. Security configuration (mongodb_user could help with this)
4. Service and/or automatic startup configuration for the MongoDB instance

The mongodb_shard and mongodb_balancer modules also require some missing pieces:

1. Config Server replica set, with mongod.conf files
2. At least one running mongos instance, with mongos.conf file
3. Replica sets configured as Shard Servers

Besides the software installation, the major holes are around configuration files. To evaluate coverage for the other modules or take a deeper look at the main components, we need some solution to get MongoDB installed and configured.

Some Options to Get MongoDB on the EC2 Instance

Building on the ideas in Provision EC2 Instances for a MongoDB Cluster with Terraform, there are three obvious options:

1. Use the Bitnami AMI to spin up EC2 instance in Terraform with MongoDB already installed
2. Run custom Ansible playbooks with Terraform to install and configure the MongoDB instance
3. Use custom Ansible playbooks in Packer to build a custom AMI with MongoDB to use in Terraform

Subsequent blog posts will explore each of these options.