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
  • https://github.com/aclark4life/kitsune-vagrant
• 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 (Open Virtualization Format archive) 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

Guest Machine Loses Internet Access

If your host machine changes network address while the guest machine is up, the guest machine will lose 'net access. Restart the guest machine to fix.