ansible

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.

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:

Ansible Playbooks for Drupal 8 Testing and Mac Dev

Lately, I've been working a lot with Ansible, a simple but powerful infrastructure management platform. I now use Ansible playbooks and ad-hoc commands to manage all of Midwestern Mac's infrastructure (this site, Hosted Apache Solr, Server Check.in, and many ancillary servers), and as a result, I've started using Ansible for pretty much any kind of work I need to do in development—including configuring my own Mac, and developing with Drupal 8.

Meet Ansible

For those who haven't heard of Ansible before, it's often described as being a little like Puppet or Chef, used for configuration management. You define the configuration of a server, and Ansible makes sure the server is configured as defined. But Ansible goes quite a bit further—it's also great for deploying applications (especially in tandem with tools like Jenkins), running commands on servers, and day-to-day management of a few, hundreds, or even thousands, of servers—it's an end-to-end configuration management tool. Ansible also has a great, and rapidly-growing community, building it up and making it markedly better every release.

Ansible uses YAML to define configuration (just like Drupal 8!), and is relatively easy to pick up, especially if you already have some experience on the command line. You can read more about it in a book I'm writing, Ansible for DevOps, and hopefully, I'll be able to tell you more about Ansible in person at DrupalCon Austin—I've submitted a session titled DevOps for Humans: Ansible for Drupal Deployment Victory! (please leave a comment and let me know what you want to hear!).

Drupal development VM (Vagrant + Ansible)

I used to use MAMP (a simple-to-install Apache + MySQL + PHP setup for Macs) for all my development, which made adding virtual hosts to Apache relatively simple. However, there are many downsides to developing with MAMP—I could never configure things like drush, APC, the version of PHP, MySQL, or auxiliary tools like XDebug and Solr, exactly how I wanted or needed them.

Getting a file from a Samba server in an Ansible playbook

For a project I'm working on, I needed to make one of my Ansible playbooks grab an archived file off a Windows share using smbclient.

There are a few concerns when doing something like this:

There are a few required dependencies that need to be installed and configured.
Unless you have a really insecure windows share, you need a username and password to access the share—and you should never put credentials into any kind of plaintext file!
Many Windows-based environments also need the appropriate workgroup set in Samba's configuration file.

I'll dive right in and show you how to set up samba and grab a file from a share in an Ansible playbook:

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:

VirtualBox, Vagrant, and Ansible: local development environment prowess

I recently gave a presentation titled Local Development Environments - Vagrant, VirtualBox, and Ansible. The presentation explains the importance and efficacy of using (and how to use) local Virtual Machines under VirtualBox, managed with Vagrant, and provisioned with Ansible, especially in comparison to using more traditional tools like WAMP, MAMP, or other prepackaged server solutions.

By the end of the presentation, you'll hopefully see how easy—and powerful—it is to create virtual machines for local web and application development.

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

Easily manage Apache VirtualHosts with Ansible and Jinja2

Server Check.in's entire infrastructure is managed via Ansible, which has helped tremendously as the service has grown from one to many servers.

Ansible Borg Cow
cowsay and Ansible were made for each other.

One pain point with running Apache servers that host more than one website (using name-based virtual hosts) is that the virtual host configuration files quickly get unwieldy, as you have to define the entire <VirtualHost /> for every domain you have on the server, and besides Apache's mod_macro, there's no easy way to define a simple structured array of information and have the vhost definitions built from that.

Fixing SSH unknown error when provisioning a Vagrant VM with Ansible

While getting a local VM managed by Vagrant to work with Ansible for provisioning, I kept getting errors like the following:

fatal: [solr] => SSH encountered an unknown error during the connection. We recommend you re-run the command using -vvvv, which will enable SSH debugging output to help diagnose the issue

[vm-name-here] : ok=0    changed=0    unreachable=1    failed=0

FATAL: no hosts matched or all hosts have already failed -- aborting

Ansible failed to complete successfully. Any error output should be
visible above. Please fix these errors and try again.

It seems that Ansible is unable to connect to the VirtualBox host via SSH because the entry for 127.0.0.1 in my ~/.ssh/known-hosts file is set for my local computer, and not for any VMs. To work around this limitation, I created a new file, ~/.ssh/config, with the contents:

Host 127.0.0.1
        StrictHostKeyChecking no
        UserKnownHostsFile=/dev/null

Now, when Ansible tries connecting during provisioning, it doesn't check the host key for localhost, and provisioning succeeds.

DevOps, Server Deployment and Configuration Management

For the past few years, as the number of servers I manage has increased from a few to many, and the services I operate have required more flexibility in terms of adding and removing similarly-configured servers for different purposes, I've been testing different deployment and configuration management tools.

Many developers who are also sysadmins have progressed much the same way as I have, beginning by building everything by hand without documenting the process, then documenting the build with text files, and ultimately scripting builds with bash scripts. However, none of these techniques allow fast provisioning, continuous configuration management, or the flexibility required to make constantly-evolving applications adapt to the requirements of the day.

In recent years, 'DevOps' (better integration of development and operations) has become a hot buzzword and mantra of companies espousing agile development methodologies.

A Very Brief (and woefully inadequate) Philosophy of DevOps

Devops - fire meme
Source: DevOps.com

Servers, like instances of applications, should be managed via version-controlled configuration, and should be disposable (a common war cry: Trash Your Servers and Burn Your Code. If a server blows up, or if another few application servers are needed, they should be able to be provisioned or decommissioned in minutes, not hours (much less days or weeks!), and should be able to be provisioned and decommissioned automatically, without human intervention.

Subscribe to ansible