In support of my mission to make local development easier and faster, I've released boxes for four of the most popular Linux distributions I use and see used for Drupal sites: CentOS 6/7 and Ubuntu 12.04/14.04.
In the middle of preparations for next month's Souls & Goals soccer match, I've also been very busy with Ansible-related activities.
I'm still making progress in writing Ansible for DevOps (over 45,000 words, and over 900 people have already bought the book on LeanPub!), and I've been invited by the folks at Professional VMWare to present in their #vBrownBag DevOps Series! I'll be talking about Ansible for an hour or so, and I'll be sure to post the link to the presentation after it's over.
You can join the presentation live (starts at 7:30 p.m. CST tonight, October 29) by registering at http://professionalvmware.com/brownbags/.
Earlier today, the Drupal Security Team announced SA-CORE-2014-005 - Drupal core - SQL injection, a 'Highly Critical' bug in Drupal 7 core that could result in SQL injection, leading to a whole host of other problems.
While not a regular occurrence, this kind of vulnerability is disclosed from time to time—if not in Drupal core, in some popular contributed module, or in some package you have running on your Internet-connected servers. What's the best way to update your entire infrastructure (all your sites and servers) against a vulnerability like this, and fast? High profile sites could be quickly targeted by criminals, and need to be able to deploy a fix ASAP... and though lower-profile sites may not be immediately targeted, you can bet there will eventually be a malicious bot scanning for vulnerable sites, so these sites need to still apply the fix in a timely manner.
In this blog post, I'll show how I patched all of Midwestern Mac's Drupal 7 sites in less than 5 minutes.
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).
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:
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'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:
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!
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.
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.