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
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 ================================================================================ RuntimeError ------------ 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'