86

You have a project which has got some SW requirements to run (e.g.: a specific version of Apache, a version of PHP, an instance of a MySQL database and a couple of other pieces of software).

You have already discovered Vagrant, so your virtual environment is all setup. You can create boxes out of your configuration files and cookbooks.

You have also understood the advantages of a Continuous Integration system such as Jenkins.

Now you would like to combine these two worlds (Vagrant and Jenkins) to get the perfect Continuous Integration Environment. To be more specific, you would like not to install the SW required by your project on the machine running Jenkins, but you would like to use the virtual environment provided by Vagrant to periodically build your project on the top of it. The CI software (Jenkins) will build the Vagrant box for you and build and test your project on the top of it.

How would you setup your environment to achieve this?

Roberto Aloi
  • 30,570
  • 21
  • 75
  • 112
  • 4
    In addition, your Jenkins setup is a Vagrant box, so you can run this CI environment on multiple platforms, as there are lots of differences between them. – Stephan Eggermont Aug 09 '11 at 11:46
  • 1
    Have you created such environment ? Combination of Docker & Jenkins is already well known, however, it will not suffice for Windows environments in which case the only good option, IMO, is Vagrant + Jenkins. There are some aspects to consider, for instance do we really need slaves and in what contexts or could we use single server to create vagrant build environment per project on demand (in many companies only few projects are constantly building, majority is rarely build), or should we use this on top of the deduplication system to reduce disk footprint. – majkinetor Nov 03 '14 at 13:30

3 Answers3

36

it is a good solution for build system, my suggestion:

  1. Your current jenkins works as master CI (probably started by user jenkins)
  2. Create another user in same machine or another machine to work as jenkins slave mode
    • jenkins slave can be invoked from jenkins master, and it can use different user like vagrant who had permission and environment for vagrant, therefore it will not interfere the original jenkins master server
    • create your base vagrant box, then it can be reused to speedup for your deployment
  3. Most of the installation information (packages) could be managed by puppet (or chef) to be loaded into your vm box.

Probably you can take a look at veewee, which can create vagrant box on fly.

Here is the Make CI easier with Jenkins CI and Vagrant for my guideline for this suggestion.

Larry Cai
  • 55,923
  • 34
  • 110
  • 156
  • 2
    Your link is broken unfortunately – langlauf.io May 24 '19 at 16:00
  • 4
    In case someone is interested in the broken link, here is a copy of [Make CI easier with Jenkins CI and Vagrant](https://web.archive.org/web/20160209123318/http://www.larrycaiyu.com/blog/2011/10/21/make-ci-easier-with-jenkins-ci-and-vagrant/) – Gilberto Treviño Sep 06 '19 at 16:00
12

You could try the Vagrant Plugin for Jenkins that currently supports Jenkins CD 1.532.3

You can see a demo of this plugin running at http://unethicalblogger.com/2012/03/13/vagrant-plugin-in-action.html

Steve Mitcham
  • 5,268
  • 1
  • 28
  • 56
Christophe Furmaniak
  • 845
  • 9
  • 15
  • 7
    this plugin doesn't support Jenkins above 1.490 so that's a big limitation :-( – kenyee Jan 08 '14 at 17:46
  • does not support vagrant running on slaves too :( – Christophe Furmaniak Jul 01 '14 at 08:33
  • Why do you need plugin at all, you can perfectly start vagrant from the shell. – majkinetor Nov 03 '14 at 13:30
  • 1
    Yes, but then you have to handle all the lifecycle of the VM by yourself (create, destroy or not at the end of the job, ...). The idea behind the plugin is that the plugin does that for you and then you can focus on your main purpose: use a VM as an isolated container. – Christophe Furmaniak Dec 04 '14 at 13:29
  • 2
    The mentioned plugin has anoying issues, which are still not fixed (https://issues.jenkins-ci.org/browse/JENKINS-26326), and development halted a year ago. Would not recommend. – Ross Aug 06 '15 at 12:47
  • 1
    Running the vagrant instance on demand to do the build sounds like the right thing to do. If this plugin still dysfunctional? – Atif Jun 10 '16 at 06:01
1

Personally I'd suggest using Hashicorp Packer to build out your Vagrant boxes for developers, and then use it to also output a Docker or AWS or OpenStack image that you can run on your CI system. Vagrant is an awesome tool, but the overhead of VMs can be a little high for a CI system to constantly spin them up and down, especially if you want really fast feedback.

At a former client we basically booted the Vagrant machines once with the system, and then ran Docker/virtualenv builds inside of those VMs and we periodically destroyed them when there was a major upgrade or an issue with the environment not behaving correctly.

https://www.packer.io/docs/builders/openstack.html

dragon788
  • 3,583
  • 1
  • 40
  • 49
  • If I may ask, did you run jenkins as a separate user ?? If so how did you manage to provide access to vagrant ?? Thanks – Jaswanth Manigundan May 09 '17 at 01:28
  • As long as vagrant is installed normally it is put on the system path. The boxes themselves are normally loaded to the current user's home directory but you can override the vagrant home with an environment variable. We combined all of these plus making the box pull with a specific version part of the build process so that it was cached once and then reused. – dragon788 May 09 '17 at 01:44