Managing a flotilla of Macs
One of my side projects at my previous job was managing our team’s small fleet or flotilla of mac portables, and maintaining something resembling a common build for about twenty machines.
But why?
There were a few reasons we embarked on running our own machines within the team:
- Have a standardised and hardened OS X build
- To maintain a fleet reserve for when machines were out for repairs etc.
- Provide individual developers with flexibility for customisation
- New machines ready in hours versus days / weeks
Did you not have an IT department?
Yes we did. However from experience at numerous companies, corporate IT takes a one size fits all approach to fleet management. Well intended things like an anti-virus that scans every file on creation seem like a good idea, but absolutely cripple a brand-new Macbook Pro running an iOS compilation.
So we broke away, and relied on corporate IT for only hardware support.
The origins of a solution
In late 2012, we were seeing large divergence in our development environments; as a fairly flexible team it wasn't uncommon for someone to pick up a project for a few days to help on a problem. This is when you would see issues with behaviour being slightly different as “User A” was using RVM and “User B” was using the new hotness (RBEnv).
Around this time I saw @wfarr speaking about “The Setup” and how Github was using Puppet to manage all their machines, with a mention of it becoming open source “soon”.
Roll on to February 2013 and the release of BOXEN; at this point I started to experiment with what our standardised laptop would look like. This included researching various security standards, as well as getting a much better understanding how Puppet works with OS X.
A “complete”ish solution
With the release of Mavericks at the end of 2013, I started to roll out BOXEN optionally to anyone in the team who wanted it. The build I ended up with looked like this:
- A standard Boxen build
- Corporate applications such as Office
- A security baseline based on guidance from various agencies
Over time this evolved a little, and everyone gets their own personal manifests to allow them to install things like Minecraft.
The use of BOXEN became almost universal during 2014, as a lot of the team either got a new machine or did a full rebuild.
The outcome
BOXEN solved a lot of problems for us as a team but, it was not the holy grail, as it comes with its own set of problems including:
- Everyone needs to learn a little puppet
- Sometimes a “little puppet” is a huge rabbit hole of stack traces
- We had no way of tracking when puppet runs were being undertaken successfully only when they failed.
- Most people (myself included) still end up ignoring it occasionally and just installing that package.
All this being said, BOXEN did solve one of our key problems upfront which was making our standard, out of the box experience much cleaner and repeatable. Also developers suffering a hardware failure were back up-and-running the same day.
What would I change?
There’s a few things I would like to do different next time around:
- A more human-friendly interface than the command-line
- Track puppet runs and what they are doing
- Maintain an actual inventory of the flotilla more information than we have X Macbooks
- Do less with Puppet aka. make it do the bare essentials
In any future deployments I would likely take a few leads from the Google macops team and would encourage looking at what they are doing with their mac fleet.
