I’ve been working on a mongodb installation and configuration cookbook which allows me to install & if required make custom configurations . It allows me to Install and configure a standalone mongodb installation or a replica set.
Developing this cookbook ( still a work in progress ) has led me to take a loosely coupled approach to its development such that I did not want to force a dependency on any previous recipe. This has meant a number of rules would need to be followed to use the cookbook properly rather than imposing any constraints.
So why did I come to this conclusion that flexibility and thus loose coupling was a requirement for this particular cookbook:
The use of a replica set and the fact you may want to seed the mongodb set up with data from a backup did gave me food for thought. When spiking the various configuration scenarios I found that if I updated my current master via a data dump where I had decided to stop the master mongodb instance while I copied the data into the data folder I found the data wasn’t being replicated. This was because one of the slaves had then taken over as the master and you can’t really force a master( without pain ) in a replica set ( maybe 10gen can advise on that one although I guess if I’d made sure the owner of the files was correct before the copy I may not have hit the mongo having a fit stage) so I needed to cater for that one.
Seeding mongo before a replica set is created seems like a nice approach to me anyway.
In a standalone mongodb instance I’m probably not worried about Raid so the recipe to create the Raid device shouldn’t be a constraint and while I’m at it why can’t you set up a replica that just uses instances with local storage?
I want to add recipes to create the job to undertake regular backups and maybe one to do a restore. But I may not want to use them.
Suddenly the list of things I want my mongo cookbook to do is growing. So I have done what is required to deliver the functionality that is required by the client I needed to do the Chef work for and now I can pimp my cookbooks till I’m happy enough to share it with the community .
(The whole ‘just enough’ ethos is something I mean to talk about here but not now)
I want the recipes to be easy to use and understood by people new to Chef and also to mongodb as I do not believe just because you have a sophisticated tool like Chef that should mean your cookbooks should be overly complicated. Keeping it simple makes maintenance easy and encourages others to expand upon it appropriately if they follow the rules. Mongodb is very easy to get up and running so why use a tool to make it suddenly obtuse?
So the rules to date :
Obviously you need to have mongo installed as a starting point. I couldn’t really mandate the use of the installation recipe as it may be an existing set up . ( I have to modify this so it brings down a specified version rather than just the latest version from the 10gen repository) .
Each recipe is to be used to carry out a single function e.g install mongdb, configure the configuration file , start mongodb etc. The combining of functions is discouraged
Each subsequent recipe can be run independently of the others or be combined as a role this meant making sure I had a recipe to start mongodb so this could be dropped in as say part of a role or workflow .
The use of templates and variables to encourage flexibility .
When I get to a point I feel the cookbook is pimped appropriately I’ll post a dissection and some guidance .