Hudson supports the "master/slave" mode, where the workload of building projects are delegated to multiple "slave" nodes, allowing single Hudson installation to host a large number of projects, or provide different environments needed for builds/tests. This document describes this mode and how to use it.
A "master" is an installation of Hudson. When you weren't using the master/slave support, a master was all you had. Even in the master/slave mode, the role of a master remains the same. It will serve all HTTP requests, and it can still build projects on its own.
Slaves are computers that are set up to build projects for a master. Hudson runs a separate program called "slave agent" on slaves. There are various ways to start slave agents, but in the end a slave agent and Hudson master needs to establish a bi-directional byte stream (for example a TCP/IP socket.)
When slaves are registered to a master, a master starts distributing loads to slaves. The exact delegation behavior depends on configuration of each project. Some projects may choose to "stick" to a particular machine for a build, while others may choose to roam freely between slaves. For people accessing Hudson website, things works mostly transparently. You can still browse javadoc, see test results, download build results from a master, without ever noticing that builds were done by slaves.
Follow the Step by step guide to set up master and slave machines to quickly start using distributed builds.
Pick the right method depending on your environment and OS that master/slaves run.
Hudson has a built-in SSH client implementation that it can use to talk to remote sshd and start a slave agent. This is the most convenient and preferred method for Unix slaves, which normally has sshd out-of-the-box. In this set up, you'll supply the connection information (the slave host name, user name, and credential)
, and Hudson will do the rest of the work by itself, including copying the binary needed for a slave agent, and starting/stopping slaves.
\[Where is this documented?\]
This is the most convenient set up on Unix.
For Windows slaves, Hudson can use the remote management facility built into Windows 2000 or later (WMI+DCOM, to be more specific.) In this set up, you'll supply the username and the password of the user who has the administrative access to the system, and Hudson will use that remotely create a Windows service and remotely start/stop them.
This is the most convenient set up on Windows.
If the above turn-key solutions do not provide flexibility necessary, you can write your own script to start a slave. You place this script on the master, and tell Hudson to run this script whenever it needs to connect to a slave.
Typically, your script uses a remote program execution mechanism like SSH, RSH, or other similar means (on Windows, this could be done by the same protocols through cygwin or tools like psexec), but Hudson doesn't really assume any specific method of connectivity.
What Hudson expects from your script is that, in the end, it has to execute the slave agent program like
java -jar slave.jar, on the right computer, and have its stdin/stdout connect to your script's stdin/stdout. For example, a script that does "
ssh myslave java -jar ~/bin/slave.jar" would satisfy this.
(The point is that you let Hudson run this command, as Hudson uses this stdin/stdout as the communication channel to the slave agent. Because of this, running this manually from your shell will do you no good).
A copy of
slave.jar can be downloaded from
http://yourserver/hudson/jnlpJars/slave.jar. Many people write scripts in such a way that this 160K jar is downloaded during the script, to make sure the consistent version of
slave.jar is always used.
Technically speaking, in this set up you should update
Launching slaves this way often requires an additional initial set up on slaves (especially on Windows, where remote login mechanism is not available out of box), but the benefits of this approach is that when the connection goes bad, you can use Hudson's web interface to re-establish the connection.
Another way of doing this is to start a slave agent through Java Web Start (JNLP). In this approach, you'll interactively logon to the slave node, open a browser, and open the slave page. You'll be then presented with the JNLP launch icon. Upon clicking it, Java Web Start will kick in, and it launchs a slave agent on the computer where the browser was running.
This mode is convenient when the master cannot initiate a connection to slaves, such as when it runs outside a firewall while the rest of the slaves are in the firewall. OTOH, if the machine with a slave agent goes down, the master has no way of re-launching it on its own.
On Windows, you can do this manually once, then from the launched JNLP slave agent, you can install it as a Windows service so that you don't need to interactively start the slave from then on.
This launch mode uses a mechanism very similar to Java Web Start, except that it runs without using GUI, making it convenient for an execution as a daemon on Unix. To do this, configure this slave to be a JNLP slave, take
slave.jar as discussed above, and then from the slave, run a command like this:
$ java -jar slave.jar -jnlpUrl http://hudson.acme.org/computer/slave-name/slave-agent.jnlp
Also note that the slaves are a kind of a cluster, and operating a cluster (especially a large one or heterogeneous one) is always a non-trivial task. For example, you need to make sure that all slaves have JDKs, Ant, CVS, and/or any other tools you need for builds. You need to make sure that slaves are up and running, etc. Hudson is not a clustering middleware, and therefore it doesn't make this any easier.
This section describes my current set up of Hudson slaves that I use inside Sun for my day job. My master Hudson node is running on a SPARC Solaris box, and I have many SPARC Solaris slaves, Opteron Linux slaves, and a few Windows slaves.
hudsonand a group called
hudson. All computers use the same UID and GID. (If you have access to NIS, this can be done more easily.) This is not a Hudson requirement, but it makes the slave management easier.
/var/hudsondirectory is set as the home directory of user
hudson. Again, this is not a hard requirement, but having the same directory layout makes things easier to maintain.
/var/hudsonhave all the build tools beneath it --- a few versions of Ant, Maven, and JDKs. JDKs are native programs, so I have JDK copies for all the architectures I need. The directory structure looks like this:
/var/hudson +- .ssh +- bin | +- slave (more about this below) +- workspace (hudson creates this file and store all data files inside) +- tools +- ant-1.5 +- ant-1.6 +- maven-1.0.2 +- maven-2.0 +- java-1.4 -> native/java-1.4 (symlink) +- java-1.5 -> native/java-1.5 (symlink) +- native -> solaris-sparcv9 (symlink; different on each computer) +- solaris-sparcv9 | +- java-1.4 | +- java-1.5 +- linux-amd64 +- java-1.4 +- java-1.5
/var/hudson/.sshhas private/public key and
authorized_keysso that a master can execute programs on slaves through ssh, by using public key authentication.
/var/hudsonto slaves (except
/var/hudson/workspace) I use this to replicate tools on all slaves.
/var/hudson/bin/launch-slaveis a shell script that Hudson uses to execute jobs remotely. This shell script sets up
PATHand a few other things before launching
slave.jar.Below is a very simple example script.
#!/bin/bash JAVA_HOME=/opt/SUN/jdk1.6.0_04 PATH=$PATH:$JAVA_HOME/bin export PATH java -jar /var/hudson/bin/slave.jar
cvsinstalled and available in PATH.
Some slaves are faster, while others are slow. Some slaves are closer (network wise) to a master, others are far away. So doing a good build distribution is a challenge. Currently, Hudson employs the following strategy:
If you have interesting ideas (or better yet, implementations), please let me know.
Typically, you start with a master-only installation and then much later you add slaves as your projects grow. When you enable the master/slave mode, Hudson automatically configures all your existing projects to stick to the master node. This is a precaution to avoid disturbing existing projects, since most likely you won't be able to configure slaves correctly without trial and error. After you configure slaves successfully, you need to individually configure projects to let them roam freely. This is tedious, but it allows you to work on one project at a time.
Projects that are newly created on master/slave-enabled Hudson will be by default configured to roam freely.
One might consider setting up the Hudson master on the public network (so that people can see it), while leaving the build slaves within the firewall (because having a lot of machines on the internet is expensive.) This can generally be made to work in two means:
Note that in both cases, once the master is compromised, all your slaves can be easily compromised (IOW, malicious master can execute arbitrary program on slaves), so both set-up leaves much to be desired in terms of isolating security breach. Build publisher plugin (which looks almost ready as of this writing) provides another way of doing this, in more secure fashion.
slave.jarso that Hudson avoids sending binary data over the network.