DevOps Zone is brought to you in partnership with:

Sys engineer with a passion for finding new ways to use Operations to enable business to move faster and more effectively. Key buzzwords and areas of interest: linux, ruby, cloud, webops, devops, kanban! Joe is a DZone MVB and is not an employee of DZone and has posted 19 posts at DZone. You can read more from them at their website. View Full User Profile

Parallel Provisioning For Speeding up Vagrant

05.04.2012
| 8564 views |
  • submit to reddit

Vagrant is an amazing tool. It's quite substantially changed my workflows in a variety of areas. It's a particularly interesting tool for building packages or running tests across multiple OS's or distributions from a single set of scripts.

A recent example of the usefulness of Vagrant is the new packaging and testing work undertaken in the Sensu project. The project set out to build a new set of native OS packages with a goal of making Sensu easy to deploy on a variety of platforms and without a lot of the friction that sometimes accompanies Ruby apps. As part of the packaging effort we needed a simple mechanism to build native packages on the relevant platforms, ie: .deb's on debian and .rpm on redhat/centos.

We ended up using a combination of Vagrant and some homegrown tools such as Bunchr.

You can see the work in these 2 repos:

Both codebases contain a para-vagrant.sh script that is used in place of the normal vagrant up to kick off parallel provisioning tasks. sensu-tests is the more interesting example as it runs a set of rspec tests against Sensu across 14 VM's and this will likely grow to encompass other OS's in the future. The tests are executed as Vagrant provisioners (a combo of Chef and shell to call rspec).

The simplest way to use multi-VM's with Vagrant is the typical vagrant up. However, this will boot and run the provisioning tasks sequentially on each VM. With 14 VM's to test, this process can take a long time.

Can we speed this up? Yes. In fact we were able to reduce the time taken to run the sensu-build tasks from about 33 minutes to 12 minutes, and reduced sensu-tasks from almost 90 minutes to 15!

Here was the first attempt at a parallelization script:

#!/bin/sh
 
# concurrency is hard, let's have a beer
 
MAX_PROCS=4
 
parallel_provision() {
    while read box; do
        echo "Provisioning '$box'. Output will be in: $box.out.txt" 1>&2
        echo $box
    done | xargs -P $MAX_PROCS -I"BOXNAME" \
        sh -c 'vagrant provision BOXNAME >BOXNAME.out.txt 2>&1 || echo "Error Occurred: BOXNAME"'
}
 
## -- main -- ##
 
# start boxes sequentially to avoid vbox explosions
vagrant up --no-provision
 
# but run provision tasks in parallel
cat <<EOF | parallel_provision
centos_5_64
centos_5_32
ubuntu_1004_32
ubuntu_1004_64
EOF

There are 2 steps to the process:

  • Sequentially boot each VM listed in the Vagrantfile, but without running provisioners (vagrant up --no-provision). The reason we do the bootups sequentially is to avoid potential kernel panics that VirtualBox is prone to do, at least on OSX.

  • Feed a list of VM's into xargs to execute $MAX_PROCS vagrant provision $BOXNAME processes in parallel. xargs will manage the concurrency for us.

The final script we used with the sensu-tests repo is a little different than the above example, which can be viewed here: para-vagrant.sh. This script reduced the time it takes to run the full test suite from over 90 minutes to 15 minutes. The differences in this final version of the script:

  • uses GNU parallel instead of xargs for better handling/grouping of the output from the vagrant provision processes.

  • reads the list of VM's from a JSON file (the Vagrantfile also uses this JSON file). To add/remove new VM's, you only need to edit one file now.

Future?

It should be possible to make the process go even faster by parallelizing the bootup phase, but I have not tried this yet because I'm worried about VirtualBox stability.

Also, I'm sure there's a more polished script/utility that can be written to parallelize any multi-VM Vagrantfile.

Alternatives?

As @vvuksan correctly points out, doing such short tasks with Vagrant is probably always going to be a little slow due to the overhead in spinning up VM's, so a possible alternative maybe LXC. There's already a Vagrant-like tool for LXC called toft. LXC should work fine for workflows that include only various Linux distributions, but won't help if you need to test other OS's like FreeBSD or Solaris.

Published at DZone with permission of Joe Miller, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Paul Russel replied on Sun, 2012/06/10 - 9:21am

So happy I read this - "the reason we do the bootups sequentially is to avoid potential kernel panics that VirtualBox is prone to do" - I hit this all the time when trying to manually start multiple boxes at the same time.  I'm going to give your script a try - thanks for sharing!

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.