devops

Fix for Ansible hanging when used with Docker and TTY

For almost all my Ansible roles on Ansible Galaxy, I have a comprehensive suite of tests that run against all supported OSes on Travis CI, and the only way that's possible is using Docker containers (one container for each OS/test combination).

For the past year or so, I've been struggling with some of the test suites having strange issues when I use docker exec --tty (which passes through Ansible's pretty coloration) along with Ansible playbooks running inside Docker containers in Travis CI. It seems that certain services, when restarted on OSes running sysvinit (like Ubuntu 14.04 and CentOS 6), cause ansible-playbook to hang indefinitely, resulting in a build failure:

How I test Ansible configuration on 7 different OSes with Docker

The following post is an excerpt from chapter 11 in my book Ansible for DevOps. The example used is an Ansible role that installs Java—since the role is supposed to work across CentOS 6 and 7, Fedora 24, Ubuntu 12.04, 14.04, and 16.04, and Debian 8, I use Docker to run an end-to-end functional test on each of those Linux distributions. See an example test run in Travis CI, and the Travis file that describes the build.

Note: I do the same thing currently (as of 2019), but now I'm using Molecule to tie everything together; see Testing your Ansible roles with Molecule.

What's new in Ansible 2 and Ansible Galaxy 2 (Presentation)

Last night I presented the following slides at the Ansible St. Louis meetup at Riot Games. In the presentation, I mention the motivation behind Ansible and Galaxy 2, and run through most of the major changes and new features:

I've incorporated many of the new features in Ansible 2.0 in my book, Ansible for DevOps, and will be rewriting a few of the examples in the book to take advantage of new features in Ansible 2 soon!

#vBrownBag DevOps presentation - Oct 29 [Updated]

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

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!

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.

CI: Deployments and Static Code Analysis with Drupal/PHP

CI: Deplyments and Code Quality

tl;dr: Get the Vagrant profile for Drupal/PHP Continuous Integration Server from GitHub, and create a new VM (see the README on the GitHub project page). You now have a full-fledged Jenkins/Phing/SonarQube server for PHP/Drupal CI.

In this post, I'm going to explain how Jenkins, Phing and SonarQube can help you with your Drupal (or hany PHP-based project) deployments and code quality, and walk you through installing and configuring them to work with your codebase. Bear with me... it's a long post!

Code Deployment

If you manage more than one environment (say, a development server, a testing/staging server, and a live production server), you've probably had to deal with the frustration of deploying changes to your code to these servers.

In the old days, people used FTP and manually copied files from environment to environment. Then FTP clients became smarter, and allowed somewhat-intelligent file synchronization. Then, when version control software became the norm, people would use CVS, SVN, or more recently Git, to push or check out code to different servers.

All the aforementioned deployment methods involved a lot of manual labor, usually involving an FTP client or an SSH session. Modern server management tools like Ansible can help when there are more complicated environments, but wouldn't everything be much simpler if there were an easy way to deploy code to specific environments, especially if these deployments could be automated to either run on a schedule or whenever someone commits something to a particular branch?

Jenkins Logo

Enter Jenkins. Jenkins is your deployment assistant on steroids. Jenkins works with a wide variety of tools, programming languages and systems, and allows the automation (or radical simplification) of tasks surrounding code changes and deployments.

In my particular case, I use a dedicated Jenkins server to monitor a specific repository, and when there are commits to a development branch, Jenkins checks out that branch from Git, runs some PHP code analysis tools on the codebase using Phing, archives the code and other assets in a .tar.gz file, then deploys the code to a development server and runs some drush commands to complete the deployment.

Static Code Analysis / Code Review

If you're a solo developer, and you're the only one planning on ever touching the code you write, you can use whatever coding standards you want—spacing, variable naming, file structure, class layout, etc. don't really matter.

But if you ever plan on sharing your code with others (as a contributed theme or module), or if you need to work on a shared codebase, or if there's ever a possibility you will pass on your code to a new developer, it's a good idea to follow coding standards and write good code that doesn't contain too many WTFs/min.

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.