A copy of
slave.jar can be downloaded from
http://yourserver:port/jnlpJars/slave.jar . Many people write scripts in such a way that this 160K jar is downloaded during the running of said script, to make sure the ensure that a consistent version of
slave.jar is always used. The Such an approach eliminates the slave.jar updating issue discussed below. Note that the SSH Slaves plugin does this automatically, so slaves configured using this plugin always use the correct
Example: Configuration on Unix
This section describes my current Kohsuke Kawaguchi's set up of Jenkins slaves that I use he used inside Sun for my his day job. My His master Jenkins node is running on a SPARC Solaris box, and I have he had many SPARC Solaris slaves, Opteron Linux slaves, and a few Windows slaves.
- Each computer has an user called
jenkinsand a group called
jenkins. All computers use the same UID and GID. (If you have access to NIS, this can be done more easily.) This is not a Jenkins requirement, but it makes the slave management easier.
- On each computer,
/var/jenkinsdirectory is set as the home directory of user
jenkins. Again, this is not a hard requirement, but having the same directory layout makes things easier to maintain.
- All machines run SSHDsshd. Windows slaves run cygwin sshd.
- All machines have ntp client /usr/sbin/ntpdate installed, and synchronize clock regularly with the same NTP server.
/var/jenkinshave 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/jenkins +- .ssh +- bin | +- slave (more about this below) +- workspace (jenkins 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/jenkins/.sshhas private/public key and
authorized_keysso that a master can execute programs on slaves through ssh, by using public key authentication.
- On master, I have he had a little shell script that uses rsync to synchronize master's
/var/jenkinsto slaves (except
/var/jenkins/workspace) I use this . He also used the script to replicate tools on all slaves.
/var/jenkins/bin/launch-slaveis a shell script that Jenkins 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/jenkins/bin/slave.jar
Access an Internal CI Build Farm (Master + Slaves) from the Public Internet
One might consider setting up make the Jenkins master accessible 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.typical reasons: cost and security) There are two several ways to make it work:
- Equip the master node with a network interface that's exposed to the public Internet (simple to do, but not recommended in general)
- Allow port-forwarding from the master to your slaves within the firewall. The port-forwarding should be restricted so that only the master with its known IP can connect to slaves. With this set up in the firewall, as far as Jenkins is concerned it's as if the firewall doesn't exist. If multiple hops are involved, you may wish to investigate how to do ssh "jump host" transparently using the ProxyCommand construct. In fact, with a properly configured "jump host" setup, even the master doesn't need to expose itself to the public Internet at all - as long as the organization's firewall allows port 22 traffic.