Setup Master-Slave node in Jenkins

Setup Master-Slave node in Jenkins

The machine on which your Jenkins runs your build is called a build server. In an enterprise environment,  you might have number of builds running parallel. These builds might be of different projects and different releases, but happen to trigger at the same time, and hence these run in parallel. As any process, the build process also will consume memory while it is running. While it all depends the JVM memory setting and the size of the server, however running multiple builds simultaneously will take a toll on the performance of the server. Also in an enterprise environment, it is not advisable to run all builds on one server. To solve this problem, Jenkins has the ability to run Jenkins in a distributed environment. This means, instead of running all jobs on just one machine, jobs can be distributed to run on various other machines as configured on the Jenkins master. This is called Master-Slave Configuration. The one machine where Jenkins is installed becomes the Master and all other machines which are configured to run the builds, are the Slave Machines.

In order to configure Slave machines on Jenkins, follow below steps

• Go to Manage Jenkins - Manage Nodes and click on 'Add New Node'
• Give a name to your name say 'Slave1' and check radio button 'Permanent Agent' and click on OK.
• A screen to configure Slave details will come up.. provide a description as required. Enter # of executors as per the requirement. This number will enable you to run parallel builds on this slave.
• Mention the directory path of the slave machine. This will be the workspace for Jenkins and the source code will be checked out on this path when build is run on this machine
• Give  a 'Label' as needed
• Select Usage: 'Use this build as much as possible'. If this is selected, builds will run on this, whenever all agents of master are occupied
• Select Usage: 'Only build jobs with label expression matching this node' If this is selected, the build will run on this slave, only if the job label matches with the name of this slave.. e;g: slave1_job1
• Select Launch Method: Jenkins provides few options to launch and bring up the slave agent.
• Launch Agent via Web start: 
• This is helpful when the slave machine is  a Windows machine
• Configure your node to use the "Launch slave agents via Java Web Start" launch method. Click Save
• Note the command required to launch the slave
• On the new slave node's Jenkins page, note the slave command line shown. It will be like: java -jar slave.jar -jnlpUrl http://<JenkinsHostName>:8080/computer/<nodeName>/slave-agent.jnlp -secret <some_long_hex_string>
• Obtain the slave.jar file and copy it to your new Windows slave node. In the command line noted in the last step, the "slave.jar" is a hyperlink. Click it to download the slave.jar file. Copy the slave.jar file to a permanent location on your slave machine
• Ensure that you have a java version available on your slave machine. If not, obtain and install a copy of Java
• Run the command manually from a CMD window on your slave to confirm that it works
• Open the CMD window
• Run the command (the one like java -jar slave.jar -jnlpUrl http://<JenkinsHostName>:8080/computer/<nodeName>/slave-agent.jnlp -secret <some_long_hex_string>)
• Go back to the node's web page in Jenkins.  If everything works then page should say "Connected via JNLP agent"

• Launch Agent via SSH
• Jenkins 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.
• Select the Launch method as 'Launch Agent via SSH'
• In this set up, you'll supply the connection information (the slave host name, user name, and ssh credential). Note that the slave will need the master's public ssh key copied to ~/.ssh/authorized_keys.
• Jenkins will do the rest of the work by itself, including copying the binary needed for a slave agent, and starting/stopping slaves. 
• If your project has external dependencies (like a special ~/.m2/settings.xml, or a special version of java), you'll need to set that up yourself, though.