ansible for devops

Highly-Available Infrastructure Provisioning and Configuration with Ansible

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!

Writing on LeanPub - $0.21 per word

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).

YAML best practices for Ansible playbooks - tasks

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:

A brief history of SSH and remote access

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.

Using Ansible Galaxy

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 Logo

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.

Self-Publishing a Book (on Ansible)

I've published the first portion of a book I've been writing, Ansible for DevOps. This is my first-ever book, and I've written a little about the process of writing on Server Check.in's blog: Self-publishing my first technical book on LeanPub.

Ansible for DevOps cover image

I'm excited about the early feedback I've already received—and I haven't even finished writing half the book! I'm hoping to finish the first complete draft of the book (and continue publishing it in stages on LeanPub) by summer 2014.

Self-publishing my first technical book on LeanPub

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:

Start a Node.js app with Forever and Ansible

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:

Running Ansible within Windows

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.

Running Ansible via Cygwin on Windows 7