Development Using Virtualization

Lessons learned after using Vagrant and Chef to run a Rails 3.0 project at Aelogica.

Transcript

1. Development Using Virtualization Nestor Pestelos, Jr. @ngpestelos
3. • Some context • Lessons learned using VMs for daily work • What needs improvement A Retrospective
4. Context • running monolithic Rails 3.0 app • pre-VMs: use a wiki doc as guide • introduced Vagrant on Feb 2013 • added Chef recipes on Apr 2013
5. Before Virtualization • install instructions written on a wiki page • prone to gaps and document rot • half a working day to setup our environment
6. New Developers • new developers read the wiki to get started • doesn't feel productive • half a working day to setup environment
7. New Machine • yak shave • doesn't feel productive • half a working day to setup environment
8. Peculiar Dependencies • examples: PhantomJS and PrinceXML • remember which version to install • uninstall when you leave the project
9. Enter Vagrant • programatically setup and teardown VMs • install everything we need on a box and distribute to team members • downside: keeping track of changes made to the box (think binary diffs)
10. Enter Chef • run recipes for you, in the order that you specify • recipe == what needs to be installed • started running manual chef-solo • Vagrant can kickstart a Chef run (!)
11. Running Self-Contained Boxes • Chef installs everything on Vagrant • takes a long time to get the right setup • front-loaded VMs (e.g. baked-in keys) • you will miss your beloved $EDITOR settings • YAGNI
12. Code on the Host, Test on the VM • inspired by the discourse project • companion project • application code as submodules • not all automated: e.g. ssh keys, rvm, and bundle • simple enough
13. Next steps / points for improvement • allow cap deploys both on VM and Host • nginx host mapping (still done manually) • acceptance environments (how to run the same cookbooks on EC2) • bug reporting (broken window theory)