Using Ansible to Bootstrap My Work Environment - Part I

Lately, I’ve been on a journey to learn about all things cloud and “devops”. Like any long term professional, I like my desktop work environment just so. You do a lot of configuration along the way. To get a handle on that, the first thing I started doing was maintaining all my configuration files in a private git repo. This digital ocean article is my preferred method for doing that. This was really step zero in the journey.

The other thing I began to realize is that I needed a way to quickly and repeatably bootstrap my working environment details. Should my laptop crash I should be able to quickly spin up a new one. I should also easily be able to launch a fresh cloud instance or provision a new device with some or all of the bits I might need.

Lastly, as much as you would think I would like shiny pretty hardware, the reality is I don’t need it. I might like Apple’s laptops like so many of my peers but I can get small, lightweight, and 8+ hours of battery life from a sub-$200 Chromebook. In fact I have one that I put in dev mode and use with crouton. With a Chromebook, I don’t have to care quite as much if I spill coffee on it or my 4 year old breaks it. I can just pick up another and deploy everything to get back to work with one or two commands. And while I like my business class laptop that work provides me, it’s heavier and the battery life is at best half of the Chromebook. I’m running around a lot so having the lighter device with great battery life really makes sense.

With Chrome (and Firefox, these days), a lot of apps and utilities and configuration item live there. So, yes, on the Chromebook I can just use Chrome apps for RDP, VNC and ssh as well. To those who would say you can’t get useful work done on a Chromebook, I believe my example shows otherwise. And all things I use within the browser follow my ID as well in a similar fashion. If I lose or replace a device, I just fire up Chrome, sign w/ two-factor auth and sync config and apps from archive encrypted with my personal key.

The last bit of concern are data files. This is all the work product and office documents and file history that’s not captured elsewhere such as email. Right now I don’t see any benefit to putting typical office documents under version control. Instead Google Drive and Dropbox (personal and business) are what I use for the remaining data management including sync and share. I get similar version and a certain level of backup data protection as well for all of the “data” items I use.

For the dynamic configuration data that comprises “the environment that makes Scott able to work comfortably”, what I gradually did over time was create ansible playbooks to provision a system using bare metal Ubuntu, Crouton, or AWS EC2 and lay down my private git repo and my tools. I used ansible roles to deploy some optional components that would only be relevant in a remote server (EC2) configuration and break up the tasks into reusable components.

So what does this give me?

  1. As stated above, I achieved my goal of being able to repeatably, reliably and relatively quickly create or recreate a usable working environment for myself. Manual steps and configuration are minimized and basically limited to standard, well documented installation steps depending on the target environment (eg. the first build on a laptop or a new Chromebook).

  2. I gain a lot of flexibility. I don’t have to carry a particular piece of equipment everywhere. I don’t have to worry if I don’t have my “work laptop” when I’m traveling. In a worst case scenario, I could lose my gear entirely and still be able to get back up and running in under an hour.

  3. All of the changes are tracked and testable. As I make changes in my working environment, I add necessary packages to the ansible playbooks' list of packages that I’ll need installed on a deploy. Updating my private git repos with git stage; git commit;git push is now part of my “muscle memory” when making config changes. And doing the git pull; git diff; git merge sequence frequently as well on whatever gear I’m just logging in to to ensure I have the newest revision of the working environment.

  4. Lastly, it’s been a great learning experience which is probably the most significant benefit. I built up a much better understanding of Ansible, its use cases and of AWS as well. I also learned quite a bit about usage of cloud-init along the way. And now that my configurations are all version controlled and documented via ansible playbooks, I don’t have to remember that piddly little thing I added to a file two years ago that if I don’t have it totally breaks my shell in some strange way and sends me off digging through google and old notes. Instead those details get encapsulated and deployed and tested continuously. Branching off and testing significant changes or rolling back to known-good setups is straightforward as well.

It’s an ongoing process and it’s never truly done by design. If I wanted to spin up a test instance in vagrant and use that I could. If I decided I just had to have the latest Macbook Pro it likely wouldn’t be hard to use brew in lieu of apt to achieve something similar.

In my next post, I’ll start diving into some of the gritty details.

 Share!

 
comments powered by Disqus