How I Provision My MacBook with Ansible

2019-03-20 Machine

Yesterday evening I had the pleasure of speaking at the London Ansible Meetup on the topic of provisioning my MacBook with Ansible.

Here’s the blog post version of my talk so you can follow along at home!

Story

In April 2014 I started working at YPlan. This was the first time I had separate home and work computers, both of them MacBooks. After spending much of my first two days just setting up the new one the way I liked it, I knew there had to be a better way. Of course there is, thanks to the power of automation!

I had learned Ansible just a few months before, and was using it more in my new position, so I wanted to practice it. Automating my laptop provisioning seemed like the perfect little project.

I started building it a few weeks later and it is still serving me well nearly five years since. It has saved me a bunch of time and stress, both in doing regular updates and when rebuilding my computer.

My Project

The project is on GitHub at github.com/adamchainz/mac-ansible. It has been forked or copied by many friends over the years as I've told them about it, and I've learned off them too.

Most of what it does is fairly vanilla Ansible, so it makes a great learning project. There’s a single role applied by a single playbook to a single host - it basically can’t get any simpler than that!

The role does three things:

First, Installations: Command line tools installed with Ansible’s modules for the respective package managers, such as homebrew for the Homebrew package manager which I use for command line tools, pip for Python packages such as HTTPie, homebrew_cask for installing macOS applications, and others.

Second, Configuration: This needs adding configuration files (“dotfiles”) into the correct place, either by symlinking them from the repository so I keep a copy in git, or cloning their own separate repositories such as my Sublime Text Settings. I’ve used a symlink approach so the Ansible project serves as my definitive source for these configuration files, and a single thing to back up.

Third, Cron Jobs: I have a couple of regularly running jobs, for example clean up temporary Python project files. I could probably have more of these.

I run the playbook every week based on a calendar alert emailed to me, keeping things from Homebrew on the bleeding edge. This doesn’t backfire very often. I’ve learned the lesson not to upgrade tools right before they are needed.

Intentionally Missing

There are several things that can be automated but have not been worth it for me. They might be for you, especially if you’re looking at Ansiblizing a fleet.

First: getting the computer into state to actually run Ansible. For me this requires installing Homebrew, using Homebrew to install Python and Git, using Git to clone the repository, and using pip to install Ansible. I have at least documented this though, to make things easier for my future self, forced to re-install everything at 1am before a presentation.

Second: configuring macOS itself. I actually did do this previously, but it turned out to not be worth it. macOS keeps configuration in several ‘plist’ configuration files that you can update with the defaults commandline tool. At the start when I was eager to learn, I wrote an Ansible module to wrap it. Ansible has since gained a better-implemented official osx_defaults module.

What made me give up on this was the upgrade experience. I’ve found that each new macOS changes some of the plist files and keys around, and worst I would only find when doing a fresh re-install, since it keeps the old ones when upgrading in place. Now I just remember which buttons and widgets need clicking in System Preferences (😖 trackpad “natural” scroll).

Third: configuring some (well, most) applications. For example, the macro program I use called Keyboard Maestro doesn’t seem to have an easy way of symlinking its settings files, so I just use its ‘library’ file to back up in my normal file backup (Arq).

Fourth: installing Mac App Store apps. Homebrew’s cask command can install applications but these are only free ones. Paid apps normally come through the Mac App Store, which can be automated with the mas commandline tool, but I just don’t use many paid apps so it’s not worth it to automate this for me.

Fifth: locking up passwords in dotfiles. Ansible Vault could easily be used to secure passwords, but only one of my symlinked dotfiles needs a password in it so I don’t think it’s worth me setting it up.

You Can Too

Whether you’re using macOS, Linux, another *nix, or Windows, Ansible can run on your laptop. I’d recommend automating some part of your personal IT to anyone learning Ansible or DevOps - it’s a great starter project and you are not risking destroying production!

Also, if you’re interested in helping improve Ansible’s macOS support, there’s a working group you can interact with or join. I’m not part of it but I promised John “Gundalow” Barker I’d mention it in my talk and here 😁

If you want to get started, check out these GitHub repositories for inspiration:

Thanks for reading, and thanks to Red Hat for the socks!

—Adam

Learn how to make your tests run quickly in my book Speed Up Your Django Tests.

One summary email a week, no spam, I pinky promise.

Related posts:

Tags: ansible