Vagrant, Chef, OpsWorks & You.
Previously I showed you how to use Vagrant to for your development environment. Today we’re taking it to the next step.
You will learn how to use Chef to automate the build of your environment and how to use the same recipes you wrote to create your production stack in Amazon OpsWorks.
Chef is an automation platform that transforms infrastructure into code. Making it versionable, shareable, pull-requestable.
Vagrant is a tool for building complete, development environments that are lightweight, portable and reproducible.
Amazon OpsWorks is a DevOps solution for managing applications of any scale or complexity on the AWS cloud.
Detroit a sample application for us to play with.
On the center we have the Chef recipes capable of reproducing steps to build your server. OpsWorks will use those to provision your production and staging servers in Amazon EC2; while Vagrant will provision a virtual machine for development.
Detroit & server configurations
Create the structure for the recipes and templates:
$ mkdir -p ~/ops/detroit/recipes $ mkdir -p ~/ops/detroit/templates/default
Warning: OpsWorks needs your cookbooks to be on the root path of your repo.
Let’s start by creating a couple of recipes inside the recipes folder. I’ve added comments to explain how the Chef resources work.
The nginx recipe will use this template, located in ~/ops/detroit/templates/default, with variables defined in json of the Vagrantfile or the configuration of the OpsWorks Stack.
Let’s get Vagrant on it’s feet, but first some structure.
$ mkdir -p ~/ops/vagrant/detroit
Now, let’s start creating a Vagrantfile for our Detroit app. (ops/vagrant/detroit/Vagranfile)
Pay attention to the shared folder, that should point to a clone of Detroit.
Now boot it! This will download an Ubuntu base box, install Chef using Omnibus and execute the recipes we’ve developed.
$ cd ~/ops/vagrant/detroit $ vagrant plugin install vagrant-omnibus $ vagrant up
If you go to [10.0.0.10](), the ip we configured for the virtual machine, you should see our app running. Try changing the local files (as if you were developing something) on the local copy of Detroit.
So we’ve got a recipe that can be used to create your local development environment, let’s use it then to create our staging/production environment on OpsWorks.
First create a stack, mind the fields marked in yellow:
Configure the stack to our repository and proper configurations for the environment.
Add a layer with a custom type. There are pre-configured layers for php, rails and others. I’d rather do it manually, because I like to tune things my way, but that’s just me.
Configure that layer to use the Chef recipes we’ve written:
Almost there! Now add an instance to this layer, don’t forget to start it. It will boot, execute opsworks recipes to install monitoring and such, and then it will execute your recipes. You’ll probably want to allow your ip (or any) to access that security group so you can see things online:
Chef is a powerful tool to create your infrastructure with. Your organization should have it on Git so you can collaborate on your recipes and version them. You may use the Vagrant for development, if you do you’ll get a really good dev/prod parity. I’ve found that Vagrant will speed up your DevOps workflow significantly by trying recipes locally before pushing to staging stack.
OpsWorks is also a great way to start using Chef. It’s simpler than having a hosted Chef solution. Try writing your own recipes, at the end of the day it’s better because you have full control and understanding over them, rather than using community recipes with tools like Librarian.
Have fun and take care of your infrastructure!