DevOps Zone is brought to you in partnership with:

Matthew is a Linux Consultant and Systems Administrator specialising in removing human error from configuration and deployment through the use of automation. He has supported systems of all sizes, from small businesses to home entertainment and major cloud providers. Matthew is a DZone MVB and is not an employee of DZone and has posted 9 posts at DZone. You can read more from them at their website. View Full User Profile

Putting the Butler to the Test - Part 3

02.28.2012
| 6840 views |
  • submit to reddit

Table of contents for Continuous Delivery of Server Configurations

  1. Turning a 5 Hour Manual Build and Deploy Routine Into a Single Code Commit - Part 1
  2. Deploy and Roll-back system configs with capistrano, mcollective and puppet - Part 2
  3. Part 3

The last two posts in this series have covered what the overall system will look like and how to ensure your puppet server is ready to receive the files from the SCM repo via capistrano – This post will cover setting up the test server using JenkinsCI and creating some tests.

We start by installing Jenkins.

There are packages and repositories available for just about every popular Linux Distribution as well as excellent installation instructions at the Jenkins website, so head over there now and install Jenkins from the relevant source.

Once Jenkins is up and running, we’re going to want the following plugins available:

  • git
  • rake
  • Build Pipeline

We will also want to install the following software on our server:

  • Cobbler (only needed if you don’t have a cobbler server elsewhere on your network, although I’d recommend setting up a dedicated cobbler server for testing)
  • libvirt
  • ruby
  • rubygems
  • libvirt ruby bindings
  • cucumber

Most of the above can be installed via apt or yum depending on your distro, cucumber requires installation via rubygems (see the cucumber website for more information).

OK, so let’s start to put this system together.

  1. Download a copy of cucumber-vhost from https://github.com/proffalken/cucumber-vhost

  2. Copy cucumber-vhost into your puppet modules directory
  3. Create a host in Cobbler to your requirements (There are many tutorials out there on how to do this)
  4. Edit “config.yml” and adjust for your setup – by default it’s set to use cobbler on localhost and KVM/Qemu for virtualisation
  5. Edit “features/vhost.feature” (or create your own based upon this) and replace all instances of “test” with the hostname of your system you created in Cobbler (step 3 above)
  6. Add the cucumber-vhost files to the same git repo as the puppet manifests (should just be a “git add . && git commit”)
  7. Push the git repo to a central git server (github or your own using gitosis or gitolite are perfect for this)

OK, so we’ve got everything that we need installed, we’ve got all our code in a git repo, now we need to configure Jenkins to run the tests.

  1. Log in to the Jenkins interface and create a new “Freestyle” software project
  2. Select “Git” as the SCM and provide the URL to your git-repo (you did make sure you could do a read-only pull from your repo didn’t you? ;) )
  3. Either check the “poll SCM” checkbox and set the schedule for checking new commits (* * * * * will check every minute – it’s the same format as a crontab) or configure the build to be triggered by a commit (outside the scope of this tutorial)
  4. Add an “Execute Shell” build script and add the following (remember, we deploy to staging by default!):
    • cap deploy
  5. Add a second “Execute Shell” build script and give it the following content:
    • cd /usr/share/puppet/configuration/
    • find . -type f -name *.pp -exec puppet –parseonly ‘{}’ \;
  6. Add an “Invoke Rake” task with the following content:
    • cd /usr/share/puppet/configuration
    • rake features
  7. Save the job

If you are using a tool such as “virtual-manager” or similar, you should now be able to start the job in Jenkins and watch the VM being created, installed and then destroyed.

You are now in a position to write additional tests and add them to Jenkins to test the servers, which is left as an exercise for the reader (hint: you might want to split the various scenarios into different tasks or even jobs so your VM doesn’t get destroyed before the tests are complete!).

Please feel free to ask questions etc. in the comments below, I’ll try and get to them as fast as possible.

If you’re interested in setting this up in your organisation and would like some additional help, please contact me to discuss your requirements further.

Previous in series

Source:  http://www.threedrunkensysadsonthe.net/2011/09/putting-the-butler-to-the-test/
Published at DZone with permission of Matthew Macdonald-wallace, author and DZone MVB.

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