Webdev:DevBoxVMImages

As part of bug 688911 and bug 688923, we should work on providing downloadable virtual machine images that contain ready-to-run installations of our websites. That way, a new contributor can focus on contributing, rather than learning how to install and configure a website first.

A second use case is continuous integration against a VM hosted environment. As a first stab, we're using a vagrant based VM. We'll refer to this as CI use case below.

Open questions

TBD: Should this be in an etherpad?

Image generation by hand or by machine?

• Starting by hand early to iron out process
  • Need to remember to update images on a regular basis
• Switch to Jenkins or something else for nightly builds
  • How would this work? Seems resource intensive
  • See also: bug 670471 - [tracker] set up jenkins job to export socorro vagrant VM

Is Vagrant the right tool (vs libcloud)?

• Seems like I'm fighting against some of the core Vagrant features, eg:
  • Shared folder from Host to VM
  • Custom box format rather than straight VM appliance or image
  • For CI case, we want vanilla Vagrant behaviors, but libcloud thingie would work too
• libcloud+Puppet better than Vagrant+Puppet?
  • libcloud could target VirtualBox locally and Rackspace / Amazon EC2 remotely
  • Generate self-contained VMs with source included

Vagrantfile as part of project, or separate repo?

• MDN includes Vagrantfile in the main project.
  • https://github.com/mozilla/kuma/blob/master/Vagrantfile
• Socorro has a separate socorro-vagrant project.
  • https://github.com/rhelmer/socorro-vagrant
• Probably only matters to the person or process generating the VM image
  • Since we should take care of that rather than demanding contributor to do a full vagrant up

Code on host or in VM?

• Vagrant wants to wrap a VM around a directory of source on the Host.
  • Can use familiar tools, etc
  • Shared folders from VBox to Host are slow; NFS is faster but not available to Windows.
• Better if the source for the project were git clone'ed inside the VM and shipped along with the image?
  • No more shared folder from host to VM.
  • Would need to install Samba inside VM to edit code from host.
    • That's one of the major benefits of Vagrant
  • Need to configure and use git or svn inside VM
    • Might be a bummer, might help contributors have a consistent revision control scenario
    • eg. ~/.gitconfig with contributor's name and email, etc
  • Need instructions advising a git pull after initial boot-up
  • Vagrant defaults are probably fine for CI use case

Blank slate content

• See also: https://landfill.addons.allizom.org/db/
• Need to import / generate some sample data / content to make the site useful
• Anonymized export from prod?
  • Pretty dangerous, can expose PII, should be vetted by security team
• Randomized data
  • Need to be sure it's not entirely non-sensical
• Synthetic test data
  • Need to hand-maintain
  • CI use case provides test data

Local hardware vs Rackspace VM?

• Running a VM image oneself needs a capable machine
  • Might not be an option for a MacBook Air or netbook owner
• Running a VM on Rackspace costs $$$
  • How to get an image loaded into a Rackspace VM?
• CI use case requires Jenkins server to be able to run Vagrant
  • Finding the right mix of CentOS / Ruby / vagrant gem / VirtualBox is challanging

Participating sites

• AMO?
• SUMO?
• Socorro
• Mozillians
• MDN?
  • Need proper hosting
  • http://people.mozilla.org/~lorchard/kuma-master.box
  • http://people.mozilla.org/~lorchard/kuma-mdn-with-import.box
• TBPL
• AUS
• Graphserver
• sasl-browserid

Maintaining VM images

TBD: Need to flesh out a process for most sites that an experienced webdev (eg. project lead or senior dev) follow by hand and/or automate in something like Jenkins.

Building a plain VM

Here's the general process for building a plain VM by hand, without using Vagrant:

• Grab an ISO of your base OS. (eg. MDN is using CentOS)
• Create a VirtualBox VM.
• Install the bare minimum of server packages.
  • You might want to export an OVA of this base install for future from-scratch builds.
• Create a bootstrap script that gets Puppet installed and prepares a git clone of the project's source
• As root, run puppet apply /vagrant/puppet/manifests/dev-vagrant.pp (or whatever you named it)
• Once Puppet has finished, verify that the project is working.
• Shutdown the VM and export an OVA
• Upload the exported appliance to hosting

With some more thinking, much or most of the above could be automated using libcloud or VBoxManage

Building a Vagrant box

Needs work:

• Use vagrant destroy && vagrant up to spin up a VM in VirtualBox
• Build Puppet manifests to install packages and configure the VM with a running site
  • If set up by hand, then it will always need to be done by hand.
  • If automated by Puppet manifests or other scripts, then it can be run by machine
  • Do whatever is expedient, since the VM images are the important thing
  • Someday, it might be nice to steal whatever Puppet manifests IT uses, though.
• Use vagrant package to extract a {sitename}.box image, once the site is verified to be running.
• Upload the exported {sitename}.box image to hosting site for download.

Hosting VM images

TBD: bug 688923 needs some IT collaboration to acquire hosting infra for 2-20GB VM images.

people.mozilla.org is not a good place to do this, going forward

Using VM images

TBD: What are the instructions we give contributors for using a webdev VM image?

Hints, tips, HOWTOs

TBD: Collect info and gotchas on setting up sites in VMs.