mongodb-opsworks Cookbook

mongodb-opsworks is a cookbook that is designed to take the mongodb cookbook and allow it to run successfully in AWS OpsWorks. The mongodb cookbook relies heavily on having a Chef server in place, which we know OpsWorks does not provide. However, now that OpsWorks uses chef-zero, we can successfully emulate the Chef server environment.

Attributes

mongodb-opsworks::default

node['mongodb-opsworks']['replset_layer_pattern'] - This pattern identifies a layer as a replicaset/shard. The match grouped into parantheses will be used as the shard name. Default: ^mongo-replicaset-(\S+)$
node['mongodb-opsworks']['configsvr_layer'] - The name of the layer that holds the Config Servers. Default: mongo-configsvr
node['mongodb-opsworks']['mongos_layer'] = The name of the layer that holds the mongos frontends. Default: mongo-mongos
node['mongodb-opsworks']['sharded'] = Set this to true if your Mongo cluster will be sharded. Default: false
node['mongodb-opsworks']['debug_objects'] = Set this to true if you want the node objects that will be emulated to be dumped to the log file. Used for additional debugging (since these objects are big, this is disabled by default to spare your log file.). Default: false
node['mongodb-opsworks']['instance_overrides'] - Special: Used for overriding individual node attributes.

Usage

Using mongodb-opsworks to build a simple replicaset

Build a new OpsWorks stack.

Ensure that the Chef version is 11.10 or higher. Chef 11.10 is required for chef-zero support.
Ensure that mongodb and mongodb-opsworks are in your custom cookbook archive, or in your Berksfile.
Set the cluster name in the custom stack JSON as per normal mongodb setup.

Create a new replicaset layer, mongo-replicaset-sampleset.

In this example, the replicaset name will be called "sampleset".

Set the following custom recipes in the layer:

In Setup stage: mongodb::mongodb_org_repo
In Configure stage: mongodb-opsworks::default mongodb::replicaset
- Make sure that mongodb-opsworks::default is before mongodb::replicaset!

Add instances and start it up!

Using mongodb-opsworks to build a sharded cluster

Build the stack

Build the stack for the sharded cluster.
Ensure that the Chef version is 11.10 or higher. Chef 11.10 is required for chef-zero support.
Ensure that mongodb and mongodb-opsworks are in your custom cookbook archive, or in your Berksfile.
Set the cluster name in the custom stack JSON as per normal mongodb setup.
Set the ['mongodb-opsworks']['sharded'] node to true
Set the ['mongodb']['sharded_collections'] as per normal mongodb setup.

At the end, your custom stack JSON should look something like this:

{ "mongodb": {
    "cluster_name" : "samplecluster",
    "sharded_collections": {
       "sampledb.items": "name"
    }
  },  
  "mongodb-opsworks" : {
    "sharded" : true,
  } 
}

Build the replicaset layers.

For each sharded replicaset you need, do the following:

Create a new replicaset layer, mongo-replicaset-replicasetn.

Remember, your shard name will be based on name past "mongo-replicaset-".

Set the custom recipes in the layer:

In Setup stage: mongodb::mongodb_org_repo
In Configure stage: mongodb-opsworks::default mongodb::shard mongodb::replicaset
- Order matters!

Add instances and startup.

Repeat for each shard that you want.

Build the config server layer.

Create a new layer called "mongo-configsvr".
Set the custom recipes in the layer:

In Setup stage: mongodb::mongodb_org_repo
In Configure stage: mongodb-opsworks::default mongodb::configserver
- Again, order matters!

Add instances (remember, 1 or 3!) and start.

Build the mongos layer.

Create a new layer called "mongo-mongos".
Set the custom recipes in the layer:

In Setup stage: mongodb::mongodb_org_repo
In Configure stage: mongodb-opsworks::default mongodb::mongos
- You should know by now...

Add instance and startup.

Your cluster should now be operational!

Using the instance_overrides attribute.

There is a special attribute that you can use to customize individual node that you nromally couldn't use in OpsWorks to set settings on an instance-by-instance basis. The best way to show how to use this attribute is by example. Let's say that in our simple setup, we wanted to run the replicaset real cheap and so only wanted 2 real replicaset members, but we still need an arbiter to break election ties. To do that, we would build the following custom stack JSON:

{ "mongodb": {
    "cluster_name" : "samplecluster"
  },  
  "mongodb-opsworks" : {
    "instance_overrides" : {
      "sampleset3" : {
        "mongodb" : {
          "replica_arbiter_only" : true
        }
      }
    }
  } 
}

This sets the instance sampleset3 so that it is only an arbiter. You can use method to override any attribute on a specific instance, and would be the most useful for tuning in a sharded cluster where you want the tune of one shard to be different than another layer.

Contributing

Pull requests are gladly accepted! Use the following process to get changes in.

Fork the repository on Github
Create a named feature branch (like add_component_x)
Make the change
If you think you can make self-contained tests, do so.
Make sure to test your change using OpsWorks
Submit a Pull Request using Github

License and Authors

License: Apache 2.0

Authors: Donavan Pantke (dpantke (at) appriss.com)

sabohoney/mongodb-opsworks