Dale McGladdery: Ansible Impressions

Ansible thoughtsAfter using Ansible as a personal DevOps tool for a couple of months, here are some impressions.

Context

  • Outside of work (web development) I look after six Drupal 7 and WordPress sites on shared hosting
  • My local development is done on a MacBook using apache (with some dabbling in Lando/Docker). I’ve done some wildcarding with dnsmasq and vhosts to streamline local dev site configuration. CMS code is in git repos.
  • My Ansible work is a personal project and I’m the only stakeholder
  • I learned Ansible doing this work

Ansible Tasks

I’m using Ansible to:

  • backup hosted sites to a local, external hard drive
  • automate sync’ing my local dev site from the production site
  • automate deploying Drupal 7 and WordPress updates using git as the deploy tool
  • automate parts of my WordPress update workflow

Impressions / Observations / Thoughts

In no particular order.

  • I love using the Ansible inventory for host data
    Having a single source for host data is nice. I didn’t realize how big an issue/pain point this was until it was solved.
  • Agentless is wonderful
  • Ansible has some unique terminology
    It was initially hard remembering Ansible roles are not a security thing.
  • Maintaining a consistent set of host variables was more work than I thought
    As I iterated writing playbooks and adding or changing host variables, consistently maintaining the variables across hosts became a challenge. I eventually wrote a verification playbook to ensure the required variables existed and had correct values.
  • Documenting really helped
    Writing the verification playbook in turn inspired me to document the host variables. It was more useful than I expected. This inspired me to document other project conventions. Not only did it help consistency, it helped me maintain a high-level view of what I was doing.
  • Single stakeholder is good while learning
    I’ve done a lot of refactoring as I’ve learned. I’m happy I started Ansible on a personal project with the luxury to make drastic changes.
  • The console output can be awful
    In many situations the Ansible console output is hard to read or confusing. And there is no easy method to output custom strings to help create understandable output.
  • Thinking about a playbook “wrapper”
    Ansible runs the playbook task list on each specified host and reports by host. For some playbooks it would be nice having a customizable playbook wrapper for better host specifiation and summary reporting. In the greater Ansible world there are web based interfaces with the AWX project and RedHat’s Ansible Tower product. Both are overkill for my situation. A shell script will likely be my solution.
  • Not for Drupal 8/9
    Composer and CI/CD tools provide a lot of automation options that don’t require learning a new language (a colleague is doing some cool stuff with Robo). So far I don’t see Ansible being a better solution, though it could augment a CI/CD workflow in some situations.