OpsWorks vs Chef-Server

by Roman Heinrich

A couple of days ago I was tasked to get a running MongoDB cluster, that configures itself with AWS OpsWorks.


  • create EBS volumes
  • discover other nodes with this recipe in run-list
  • create MongoDB replica set or join an existing one

The cookbook from Edelight provides most of it, and I created a fork with changes from Parse.com for EBS-Volumes creation here:

It works nicely with Chef-Server. Shouldn't be that hard to rewrite it for OpsWorks, right?

After spending two days on it, I basically gave up.

Light Problems:

  • private ssh key for my custom cookbooks repo is stored in plaintext
  • no real possibility to use Librarian/Berkshelf, you have everything in one repository
  • only one repository for custom chef cookbooks allowed
  • anything interesting requires you to use custom cookbooks
  • feedback in the web UI is rather slow
  • opsworks-agent-cli run_command update_custom_cookbooks did not work, until I have run it from the Web UI, took me a while to figure it out
  • changing JSON data for the whole Stack was not reflected on running instances, checked with opsworks-agent-cli get_json
  • even after having rebootet them, the data was just not there...

Heavy problems:

  • no possibility to have encrypted/secured data bags
  • no search available
  • the json, that represents the whole Stack, does not contain all the meta- information about chef configuration on that instances. That was all I could get:

> node['opsworks']['layers']['mongodb']['instances'].first
=> ["doughnut",

  • you have to rewrite plenty of cookbooks, that use advanced Chef-Server capabilities, like search, databags etc.

I did like thinking in:

  • Stacks
  • Layers
  • Applications
  • time/load-based Instancess
  • integrated Monitoring
  • Permission Management

But overall the limitation are too limiting. Maybe next time.