Overriding AWS opsworks templates ...with Berksfile
I do this rarely and so when I do have to override a template, I forget simple things that leave me scratching my head for hours, so I'm sharing them with you in hopes of drilling them into my head (and because i'm just a good-guy-greg):
First of all, to override a template, you have to enable custom cookbooks for your stack. Next, you have to mirror the directory structure of the AWS opsworks recipe in your own custom cookbooks repo. For example, let's say I wanted to override the default haproxy template. Starting with the top level directory of the repo itself, the path to the haproxy config template is:
opsworks-cookbooks / haproxy / templates / default / haproxy.cfg.erb
...so in my custom cookbook repo, I have to reflect the same structure:
your-custom-cookbook / haproxy / templates / default / haproxy.cfg.erb
If you are just overriding a template, do not copy anything else from the AWS repo, especially recipe *.rb files. This will cause errors. The only other thing you need, is a metadata.rb file in the root level directory of the cookbook folder you are mirroring, e.g. in the above example, in the "haproxy" directory level:
your-custom-cookbook/haproxy/metadata.rb
This is how the the AWS opsworks chef workflow recognizes that the directory contains Chef cookbook code ("I am a cookbook!").
One more detail, which is important if you are using a Berksfile, which I am:
Update your berksfile to indicate the new cookbook should be included:
cookbook 'haproxy', path: './haproxy'The AWS docs don't mention this Berksfile stuff - probably because they assume you know what you're doing, but if you basically just improvise everything like me, then maybe this will help you ^_^
Written by Robert R Arnold
Related protips
5 Responses
Thanks, it really helped me a lot! Didn't know about the need to have a metadata.rb file.
I should note that I had to remove code from unicorn's metadata.rb to make it work. I removed depends "apache2" and all other depends (leaving me with name, description, maintainer, license and version).
Hopefully this will help someone with the same problem :)
This doesn't work for me. I can't remove depends from metadata.rb file because Chef fails on OpsWorks instance complaining about a missing dependency. And leaving the dependencies is a problem because berksfile tries to lookup for opsworks-cookbooks which are not in the supermarket. My hack was to move the cookbook to the root of the repo where I have the Berksfile.
Hi, nice one.
I am thinking about override opsworks cookbooks to remove all the recipes, files, templates, etc I don't want in my machines. Basically because the booting/setup/configure takes so long. Looking at the process, one of the longest task is the download of the cookbooks. For instance, why do I want ruby cookbooks if I am running a memcached layer...
Do you think that I can override opsworks cookbooks with my own (with dir structure, but no files) with the technique you explain here?
May be there is another solution to do that.
I know this is a year later, but your post is one of the only ones that I found in regards to this. I found that including the metadata.rb file caused major problems with overlaying the cookbook. I found by digging into the cookbook location that it's probably easier to just have a repository the has the cookbooks at the top level. Don't include any of the files that your aren't overlaying, and don't include that diretory in berksfile. Then opsworks will merge the two directories, dropping your overlaid files on top of theirs, and then it looks at the merged-cookbooks directory for all cookbooks. If you include a metadata.rb and or include it in berksfile then it will also overwrite those metadata.rb files, which isn't what you want.
Thanks for the great post! This is probably how it was previously, just thought I'd post an update.
You've saved my life man! This still works in 2016!
