ansible for devops

The following is an excerpt from Chapter 8 of Ansible for DevOps, a book on Ansible by Jeff Geerling. The example highlights Ansible's simplicity and flexibility by provisioning and configuring of a highly available web application infrastructure on a local Vagrant-managed cloud, DigitalOcean droplets, and Amazon Web Services EC2 instances, with one set of Ansible playbooks.

tl;dr Check out the code on GitHub, and buy the book to learn more about Ansible!

I've been blogging for 10 years, and I've written over 800,000 words in posts. As time progresses, I try to clearly convey more information with fewer words. It's been hard to quantify the value derived from those words, however, since the only measurements I could make (e.g. a small amount of ad revenue) have been subjective at best.

For almost seven months, I've been writing Ansible for DevOps, publishing on LeanPub as I write. In that time, I've written ~41,600 words (with roughly 60% of the book complete), and have had ~800 readers purchase the book (either standalone, or in a bundle).

This post is a follow-up to a recent discussion about YAML formatting for complex Ansible playbook tasks on the Ansible Project mailing list, and will also be appearing as part of Appendix B: Ansible Best Practices and Conventions in my Ansible for DevOps book on LeanPub.

YAML, a simple configuration language

YAML's usage for describing configuration has been increasing rapidly in the past few years, and with the introduction of SaltStack and Ansible, YAML finally made its way into the server configuration management realm as a first class citizen.

YAML is a pretty simple language; it is a human-readable, machine-parsable syntax that allows for complex nested object, list, and array structures, so it is a great fit for a configuration management tool. Consider the following method of defining a list (or 'collection') of widgets:

I presented an introductory session on Ansible and how it can power Drupal infrastructure management and deployments at DrupalCon Austin 2014. Video and slides from the session, titled DevOps for Humans: Ansible for Drupal Deployment Victory!, are embedded below:

This post is an excerpt from Chapter 11: Server Security and Ansible, in Ansible for DevOps.

In the beginning, computers were the size of large conference rooms. A punch card reader would merrily accept pieces of paper that instructed the computer to do something, and then a printer would etch the results into another piece of paper. Thousands of mechanical parts worked harmoniously (when they did work) to compute relatively simple commands.

As time progressed, computers became somewhat smaller, and interactive terminals became more user-friendly, but they were still wired directly into the computer being used. Mainframes came to the fore in the 1960s, originally used via typewriter and teletype interfaces, then via keyboards and small text displays. As networked computing became more mainstream in the 1970s and 1980s, remote terminal access was used to interact with the large central computers.

2020 Update: This article is still as relevant as ever, though Galaxy now has tens of thousands of roles and also has 'Collections' now, which can include plugins, modules, and roles! If you want to learn the latest about all this stuff, check out my fully updated Ansible for DevOps, now in it's 2nd edition! It has two chapters covering roles and collections on Ansible Galaxy.

Ansible Galaxy was launched just a few short months ago, and already has over 500 roles maintained by over 225 users. The idea behind Galaxy is to give greater visibility to one of Ansible's most exciting features: reusable Roles for server configuration or application installation.

Update: Almost two years later, I've finally finished the book! You can purchase Ansible for DevOps on LeanPub, Amazon, or iTunes.

For the past year, I've seen many accounts of first-time authors finally taking the plunge and self-publishing a book on some technology or another, and finally decided to do the same.

Like many of these first-time authors, I felt I was prepared for the project, for the following reasons:

Forever is a really simple and flexible tool to daemonize Node.js apps. Instead of running them with nohup node /path/to/app.js &, run them with forever (so you can forever start [app] and forever stop [app], among other things). Server Check.in uses Ansible to deploy our Node.js apps, and there's currently no Ansible module to control forever like you control service, but you can still use the following plays to install forever and run your app:

2016 Update: If you are using Windows 10 or later, check out my newer instructions for Using Ansible through Windows 10's Subsystem for Linux.

Ansible is a simple and powerful infrastructure and configuration management tool that Server Check.in uses to manage it's infrastructure. Installing and using Ansible on Mac OS X or Linux workstations is incredibly easy, and takes all of 30 seconds to set up.