Amazon Opsworks Chef 11 Issues

At Terminus (and SingleOps before that) we’ve used Amazon OpsWorks to manage our infrastructure and ops needs. It’s slightly more customizable than Heroku, but that comes with a significant amount of ways for things to go awry.

Servers are cattle, not pets

Perhaps the most common issue seen with EC2 access and small applications is a tendency for users to do things on a specific server instance. This is a major no-no.

OpsWorks was first released with Chef 10, but by now, the default is Chef 12 and unfortunately, the original cookbooks used for Chef 10 and 11 are starting to show their age. Over the last several weeks, some of the dependencies have been upgraded to require Chef 12 or have other breaking dependencies.

First – last week,  we had an issue with buff-ignore that was resolved by adjusting our berkshelf version from 3.2 to 3.1.5; buff-ignore had updated from ruby 2.1 to ruby 2.2

This week, on Monday when we started a new server, we received another warning

Recipe Compile Error in /var/lib/aws/opsworks/cache.stage2/cookbooks/compat_resource/libraries/autoload.rb

This resource is written with Chef 12.5 custom resources, and requires at least Chef 12.0 used with the compat_resource cookbook, it will not work with Chef 11.x clients, and those users must pin their cookbooks to older versions or upgrade.

Thanks to Github issues, and some grepping of the use of compat_resource we were able to find 3 gems that were now trying to use it, so we added to our berksfile.

# Pin our Version so that we still work in chef 11
 cookbook 'build-essential', '= 3.2.0'
 cookbook 'apt', '= 3.0.0'
 cookbook 'ming', '=1.2.3'