Ansible is an automated configuration management tool that integrates well with Vagrant, CI systems, and can be used to manage your operating system, infrastructure, and your code.
Ansible, Chef, Puppet, and SaltStack are the kings in this space. Ansible is the best choice for developers because it is the simplest to learn, the simplest to walk back into after a month of disuse, and is free. Most importantly, it was also built from the ground up to support multi-node, multi-tier, orchestrated installations including zero down time rolling updates.
One of the key concepts in cloud architecture is “No pets! Only herds.”
In the olden days, it took forever to get a shiny new server. You would nurture and feed it and grow it into the perfect host for your application. If something happened to it, you (and your project) were devastated. It was your pet.
In self-service cloud, you can spin up a new server in a few minutes. You can deploy your application in perhaps less time. If one server breaks a leg, you have it destroyed and create a new one. You have a server farm and your servers are your herd.
Pet management focuses on incrementally building your server. Herd management focuses on incrementally building your server build script. Ansible is absolutely key to this whether you use it to build the whole stack from the ground up, or to coordinate container deployments among servers.
Once again, through the beauty of Homebrew
Ansible consists of playbooks and modules. Playbooks use a declarative language to define the desired end state of your server; modules interpret the declarations and bring the server to that state.
Many major infrastructure open source projects provide an Ansible playbook to install them. The Ansible community has provided playbooks to cover most of the remaining projects.
Community authors can contribute playbooks to the Ansible Galaxy. The Galaxy provides a centralized repository, community ratings, and the simplest way to install a playbook because it also manages dependencies.
Head out to http://galaxy.ansible.com, click on Browse Roles and you can search for playbooks by category or name. If you search for roles named “jenkins”, sort by Average Score, and then click on Reverse Order, you will find a 5.0 rated jenkins role by geerlingguy. Clicking on the geerlingguy link reveals that he has contributed 58 roles with a pretty high average rating. With very little effort, you will find out that this is Jeff Geerling who wrote Ansible for DevOps. Seems like a reasonable choice.
The Ansible install included ansible-galaxy which is a “package manager” for Ansible roles. Once you find a role in Ansible Galaxy, you can install it with the user and role name.
Terms: Playbooks are generally small yaml files that apply roles to servers. Roles are directories of yaml files that include plays, tasks, and other supporting files like templated configuration files, custom modules, and variants for different operating systems.
The easiest way to start playing with Ansible is to use it to provision a Vagrant. Create your vagrant with
Vagrant’s Ansible integration makes applying roles trivial. Edit your Vagrantfile and add
Now create the jenkins-playbook.yml
Let the magic begin
Ansible will update the shell with its status as it installs Java and Jenkins and some plugins. This will take a bit because it is downloading these packages in addition to installing them. We can cache these downloads for faster second uses, but we’ll leave that for a future article.
When Ansible finishes, the PLAY RECAP should show all tasks completed successfully, no failures. We can verify that by ssh’ing into the VM and grabbing the Jenkins home page.
Pretty interesting, but not so useful. Let’s make Jenkins available to our browser.
Vagrant provides port forwarding from the guest to the host and like most everything in Vagrant, it is easy. Add this to your Vagrantfile (port 4567 is just a random port).
Now, you can browse http://localhost:4567 and configure your Jenkins server.
Tip: I keep a port mapping in ~/containers/vagrant/README.md to avoid hard to resolve port collisions as the collection of vagrants grow.
This brief introduction hints at how easy using Ansible to create temporary, repeatable, infrastructure deployments is. Future articles will show how to separate provisioning from Vagrant so it can be applied to any server, writing your own playbooks for CI testing, and eventually, zero down time rolling updates. But, first, we still need to build on our foundations - figuring out how to use docker, cloud scale services, cloud scale applications, etc.