I’ve been working with Zapier’s CLI to create new Zapier tasks and it’s been pretty great. The documentation is great, the tooling around everything is really simple, easy to use and it just always works. The only small pain point I came across was how to deal with multiple environments such as staging and production but it’s a simple workaround to isolate the two.

Travis.ci offers a simple and free way to test your Ansible roles but that’s after you’ve pushed and published your code. What if you want to verify how a change looks on a machine or easily see that build error without using an existing machine? This led me down the path of locally provisioning a virtual machine and outside of a normal virtual machine that I have running, I just wanted a standalone build just for a role.

In this post I’d like to run through how to get going with an Elastic Load Balancer(ELB) within AWS via Ansible. Load balancing your web application is a simple step forward in scaling your request capacity as well as helping out with rolling deploys and promoting/retiring servers in the future. It’s incredibly simple and straightforward to get something setup with Ansible which leaves you with an easy to understand orchestration playbook.

To make context switching easier it’s always a good idea to simplify project specifics with simple bin scripts. They don’t need to do everything but they should at least be a good jump start to get the project going. Here’s a few simples ones that I’ve been using to get my local Ansible and Vagrant setup configured. I utilize Vagrant and Ansible for most of my local development environments.

If you share your Vagrantfile and Vagrant provisioning files amongst team members for your local development environment it’s nice to be able to keep some of the options in your Vagrantfile flexible. Settings like memory usage, shared folder locations, and IP addresses. There’s a Vagrant plugin that allows you to do this and it’s really simple to setup.