How Are OpsWorks' Built-In Recipes Versioned?

Question

When you set up a stack in OpsWorks, does it lock in the current built-in cookbooks version or will it use the most up-to-date version each time a lifecycle event is triggered?

For custom cookbooks, I understand that OpsWorks caches the provided recipes when they are provided rather than fetching the newest version each time, but I wonder if the same is true for the built-in cookbooks.

I'm concerned about this for a few reasons. What if the cookbooks are updated to install a different version of Apache or PHP or slightly vary their default configuration? What if I then setup a new instance in a layer in which the old recipe was used and end up with multiple servers with slightly different configurations?

Also there doesn't appear to be a way to customize which PHP5 version gets installed, so am I just at the mercy of the ubuntu package managers' decision to use the latest stable version?

I do want to continue using the latest and greatest software versions, but I would like to deploy them on my own time after I have been able to test that my application works in the new version.

Answer 1

When you set up a stack in OpsWorks, does it lock in the current built-in cookbooks version or will it use the most up-to-date version each time a lifecycle event is triggered?

When you provision a new machine, built in cookbook + custom cookbooks are requested onto the server at the same time. It gets updated only custom cookbook update is requested. This is why the recommendation is NOT copy the entire AWS cookbook into your custom cookbook. Only things you are modifying so you can benefit from standard community cookbook updates.

I'm concerned about this for a few reasons. What if the cookbooks are updated to install a different version of Apache or PHP or slightly vary their default configuration? What if I then setup a new instance in a layer in which the old recipe was used and end up with multiple servers with slightly different configurations?

This is not just a BANE, but a benefit too. It depends on how you perceive this. What maybe a performance improvement can be done, and also introduction of bugs. This needs to be kept in sync by your operations people.

You can override parts of the built in cookbook by just placing duplicates ( or customised ) versions in the same place in your cookbook. Converge option

OR the more complex but sure way :

1. implement custom recipe cookbook.
2. import opsworks cookbooks as a submodule into a folder inside your cookbooks folder.
3. symlink the cookbook that you need version controled to the main folder now
4. evaluate and update as needed specific ones

ie :

cd cookbook
git submodule add https://github.com/aws/opsworks-cookbooks external-cookbooks/opsworks-cookbooks
ln -s external-cookbooks/opsworks-cookbooks/rails rails 

This way you can update and keep version control of your infrastructure code. Make and evaluate changes and only import the changes after you've

I still recommend using converge mode with only the minor changes you require hardcoded. It will mean LESS duplication , and your will benefit from updates that maybe in the community version of the cookbooks.

If you're using a cookbook that uses the UBUNTU way to install PHP - then you will be mercy to what is in the repo. If you are using another one that does custom compiled version, then you can compile specific versions. You may have to either write your own OR find one that does build it and let you specify version via an attribute on the cookbook.