ansible

Secure your servers from Shellshock Bash vulnerability using Ansible

Now that all Server Check.in infrastructure is managed by Ansible (some servers are running CentOS, others are running Ubuntu), it's very simple to update all the servers to protect against vulnerabilities like Heartbleed or today's new Shellshock bash vulnerability.

For CentOS (or RedHat)

$ ansible [inventory_group] -m yum -a "name=bash state=latest" [-u remote_username] [-s] [-K]

For Debian (or Ubuntu)

$ ansible [inventory_group] -m apt -a "update_cache=yes name=bash state=latest" [-u remote_username] [-s] [-K]

If you have a different method of patch management, or you need to apply the fixes manually, then this method won't apply—but for most infrastructure using normal system-provided packages, using the above commands will get the fixes with minimal effort.

A little further explanation:

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:

DevOps for Humans - Ansible presentation at DrupalCon Austin

I'm still recovering from an intense week of Drupal here in Austin, TX. I kicked things off by walking around the downtown area, then taking the intensive Acquia Drupal Developer Certification exam. Once the conference started, I attended a few sessions, met a few awesome Drupalists, and learned a lot. On the last day of the 'Con (the last session, in fact), I presented DevOps for Humans: Ansible for Drupal Deployment Victory!.

I think the presentation went well, and I heard some great questions at the end which really contributed to the discussion of Ansible and Drupal deployments in general. It was a great way to finish up the official DrupalCon sessions, though it meant I was revising slides for the hundredth time during the rest of the week, instead of relaxing and enjoying DrupalCon!

Before I post a video and slides from the session, I wanted to highlight some resources for anyone who attended (or didn't attend) DrupalCon Austin:

Below is the video and slides from the DevOps for Humans presentation. Please let me know what you think!

Testing Ansible Roles with Travis CI on GitHub

This post was originally written in 2014, using a technique that only easily allows testing on Ubuntu 12.04; since then, I've been adapting many of my roles (e.g. geerlingguy.apache) to use a Docker container-based testing approach, and I've written a new blog post that details the new technique: How I test Ansible configuration on 7 different OSes with Docker.

Since I'm now maintaining 37 roles on Ansible Galaxy, there's no way I can spend as much time reviewing every aspect of every role when doing maintenance, or checking out pull requests to improve the roles. Automated testing using a continuous integration tool like Travis CI (which is free for public projects and integrated very well with GitHub) allows me to run tests against my Ansible roles with every commit and be more assured nothing broke since the last commit.

DrupalCon and DrupalCamp news + free DrupalCon ticket!

DrupalCon Austin

This week, the DrupalCon Austin sessions have been posted, and I'm thrilled to have one of my session submissions (in the DevOps track) selected: DevOps for Humans: Ansible for Drupal Deployment Victory!.

The session will go over how Ansible can be used to realize faster, easier, and more successful Drupal deployments, as well as Ansible's ability to make sure that every environment is 'like production', so you don't ever have surprises when you deploy code to its final destination.

Switching an SVN repository to Git with KDE's Svn2Git

Some places where I've worked have used SVN for version control, and while the supposed simplicity and centralization of SVN can be nice in certain situations, SVN can't hold a torch to Git's speed, flexibility, and ubiquity (nowadays) for source control. Not to mention SVN doesn't have real tags or branches, just quasi-directories that can easily be mangled into a horrific mess (I see this quite often).

I've had to use some incredibly large (10,000+ revisions, 2GB+ total size) SVN repositories, and while I've managed them using git svn sometimes (see Switching an SVN repository to Git using git svn), it's much nicer to be able to migrate the entire team from SVN to Git so everyone can work on the repository much more efficiently.

Meet Phergie, an efficient PHP IRC bot

The Drupal community uses IRC extensively for collaboration and community building. A permanent and ever-helpful fixture of the official #drupal-* IRC channels, and in the Drupal community itself, is the humble Druplicon bot. Druplicon is a Drupal-based IRC bot that was created in 2005, and is still going strong as part of the Bot module for Drupal.

Bots like Druplicon do a lot of nice things—they can remind people of things after they were away for a while, they can store facts, track karma, throw people virtual beers, store and retrieve helpful facts, and relay important information. For example, when a build fails in Jenkins, a bot can post a message in IRC. Similarly, if a server goes down, or is under heavy load, the bot could post a message.

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.

Subscribe to ansible