Monthly Archives: January 2015

TeamCity vSphere (ESXi) Integration Explained

Written by William Roush on January 25, 2015 at 5:15 pm

I found the documentation of configuration and why certain things are set up a specific way a bit lacking on the new vSphere support from TeamCity, so here we do a dive into how everything works.

I’m going to assume you have a fairly good grasp on what TeamCity is and how to manage it, if you feel I’ve skipped anything and should go into better detail drop me a message either through the site’s contact page or a comment here.

TeamCity Cloud Integration

TeamCity’s cloud integration allows you to move your build agents from machines you may have online all day to a base image you clone out and spin up as required (and as many as required in whatever combination).

Benefits:

  • You’re not limited to 3 build agent configurations with the base TeamCity install, you’re limited to 3 active at any one time. Good for multi-platform environments.
  • Resources are only used when needed.
  • Every build can be a clean build (if you trash your build agents after a build).

Drawbacks:

  • Each virtual machine being a single build agent vs multiple build agents on a single machine with multiple cores may waste resources.
  • Build times will increase due to virtual machine build time.
  • You need to move to your build agents being stateless. (I’m dumb, Jody Shumaker corrects me in the comments)

Useful Repositories

JetBrains has published the plugins required to integrate with vSphere on Github here: https://github.com/JetBrains/teamcity-vmware-plugin/. I’m very thankful they’ve open sourced this because of the hangup mentioned later with the required resource pools.

Preparing Your Base VM

  1. Install the OS of your choice (so far Windows and *nix environments are supported out of the box, plugin needs updating if you want to support more).
  2. Install VMware tools.
    • This is used by TeamCity cloud to properly configure your build agent, and is required.
  3. Install all of your build tools
  4. Install Java for TeamCity build agent (if it isn’t part of your build tools).
  5. Install TeamCity build agent.
  6. Verify it shows up in TeamCity’s unauthorized agents list, check your agent parameters and compatible configurations.
  7. Shut down TeamCity build agent service on build agent virtual machine.
    • May want to remove the build agent from the unauthorized list at this point just to clean things up, but this is up to you.
  8. Remove name, serverURL and authorizationToken from conf/buildAgent.properties on the build agent.
    • This is to make your image generic, your cloud plugin and VMware tools will auto-populate these values for you, and in the event of you wanting to tweak the base virtual machine you don’t have to worry about it booting up as a valid build agent.
  9. Shut down the VM, and snapshot it (without a snapshot your virtual infrastructure will try to clone the entire VM, this will make spin up times for build agents extremely high.

Linux Caveats

In the most recent version of VMware on some Linux platforms when you go to install VMware tools you’ll be told to use open-vm-tools instead. At least on Debian 7 (and I haven’t tested other platforms) the vmware-rpctool binary ends up in /usr/bin instead of /usr/sbin like TeamCity expects. So we’ll just make a link for it:


$> ln /usr/bin/vmware-rpctool /usr/sbin/vmware-rpctool

I have an open issue with JetBrains on it to update their documentation.

Update: No longer an issue on the latest patch, quick turn-around from JetBrains!

Configuring Your Cloud

Go to Administration > Agent Cloud (under Server Administration) and add a new profile and give it a name.

I like to use a dedicated account for vSphere that has access only to specific folder in our environment, this includes network and datastores to prevent it from doing anything to the rest of the infrastructure.

  • Terminate instance idle time – This is the time a virtual machine that is spun up will wait without a task before being shut down, I set this fairly low (10 minutes).
  • Terminate instance (after first build completed) – This will trash a virtual machine after the build process is complete, I keep this on because I find this to be one of the major reason I’m doing this.
  • Cloud type (set to VMware vSphere)
  • vCenter SDK URL – You’ll set this to https://[vCenter FQDN]/sdk, it accepts self-signed certs provided by your vCenter box by default just fine.

Next we’ll need to configure some images, click “Add Image”, select a virtual machine from the pull-down list, pick a snapshot (you’re using snapshots, right?), select a folder that the clones will go into, select a resource pool (more on that later) and set the maximum number of virtual machines you want to be able to run at once.

If you don’t have resource pools because you’re on a version of vSphere that doesn’t support them, you’ll either have to wait till I get my fork done that removes this requirement and have JetBrains pull or, or download and remove the requirement yourself (I hear an older version of the plugin doesn’t require it but haven’t verified it).

Update: JetBrains beat me to it, issued a patch, works great now.

Verification And Validation

When you build a project with zero build agents installed, it’ll go into the queue. The TeamCity cloud plugin will spin up a virtual machine for you, and when that machine is registered it should show up with the name of the virtual machine. If this is what you got, success!

If not, feel free to post comments and I’ll see if I can help out.