Master/Slave Builds
David Weintraub
The problem is that our build server is a 64 bit Linux system and
their isn't a JDK 1.3 for Linix 64 bit.
The simplest thing is to simply use our old Windows XP box where the
project is currently being built (manually, I might add). The idea
would be to make this a Jenkins slave and have our Linux box be the
Jenkins master. The Jenkins master would tell the old Windows build
box to do the build and report everything back to the Linux master.
Great. How do I do this? The documentation isn't very good, and I've
never done Master/Slave setup before. So, what do I do?
* Setup Jenkins on the slave box just as if it was a master system?
* How do I tell our Jenkins master where the slave is located and how
do I tell the slave where the master is located?
* Do I run Jenkins on the slave, or do I find that slave.jar file and run that?
Once I get everything setup, I'll update the Wiki.
--
David Weintraub
qaz...@gmail.com
Mark Waite
- Manage Jenkins (http://your-server:8080/manage)
- Manage Nodes (http://your-server:8080/computer/)
- New Node (http://your-server:8080/computer/new) - Enter a name and make it a "dumb slave"
- Click the OK button
- Assign values for the node -
- Description,
- Number of Executors,
- Remote FS-Root (I prefer C:\Hudson for Windows XP), and
- "Launch Slave Agents via JNLP" (which makes it easy to start the slave from Windows XP)
- Click the Save button
From: David Weintraub <qaz...@gmail.com>
To: jenkinsci-users <jenkins...@googlegroups.com>
Sent: Mon, March 28, 2011 4:13:06 PM
Subject: Master/Slave Builds
Les Mikesell
You should need anything installed but the slave.jar and a way to start
it, described here:
http://wiki.jenkins-ci.org/display/JENKINS/Distributed+builds
--
Les Mikesell
lesmi...@gmail.com
David Weintraub
machine the slave is on. I take it that the slave I'm configuring is
the CURRENT machine. Is this correct?
I have started Jenkins on the Windows XP box (using the JRE 6.0 that
came with Jenkins), defined the node, and got the following error:
Connecting to Old-Build
ERROR: Unexpected error in launching a slave. This is probably a bug in Jenkins
java.net.UnknownHostException: Old-Build
at java.net.Inet4AddressImpl.lookupAllHostAddr(Native Method)
at java.net.InetAddress$1.lookupAllHostAddr(Unknown Source)
at java.net.InetAddress.getAddressFromNameService(Unknown Source)
at java.net.InetAddress.getAllByName0(Unknown Source)
at java.net.InetAddress.getAllByName(Unknown Source)
at java.net.InetAddress.getAllByName(Unknown Source)
at java.net.InetAddress.getByName(Unknown Source)
at hudson.os.windows.ManagedWindowsServiceLauncher.launch(ManagedWindowsServiceLauncher.java:116)
at hudson.slaves.SlaveComputer$1.call(SlaveComputer.java:197)
at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)
at java.util.concurrent.FutureTask.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Connecting to Old-Build
ERROR: Unexpected error in launching a slave. This is probably a bug in Jenkins
java.net.UnknownHostException: Old-Build
at java.net.Inet4AddressImpl.lookupAllHostAddr(Native Method)
at java.net.InetAddress$1.lookupAllHostAddr(Unknown Source)
at java.net.InetAddress.getAddressFromNameService(Unknown Source)
at java.net.InetAddress.getAllByName0(Unknown Source)
at java.net.InetAddress.getAllByName(Unknown Source)
at java.net.InetAddress.getAllByName(Unknown Source)
at java.net.InetAddress.getByName(Unknown Source)
at hudson.os.windows.ManagedWindowsServiceLauncher.launch(ManagedWindowsServiceLauncher.java:116)
at hudson.slaves.SlaveComputer$1.call(SlaveComputer.java:197)
at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)
at java.util.concurrent.FutureTask.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
This keeps repeating every few minutes. My configuration for this node is:
Name Old-Build
Description Old Build Machine
# of executors 1
Remote FS root C:\JenkinsBuild
Labels WIN32
Usage Leave this machine for tied jobs
Launch method Let Jenkins Control this Slave as a Jenkins Servie
Administrator user name XXXXXXXX
Password XXXXX
Availability Keep this slave on line for as much as possible
Node Properties
Environment variables (None set)
Tool Locations (None set)
--
David Weintraub
qaz...@gmail.com
Les Mikesell
> When I configure another node to create a slave, it doesn't say which
> machine the slave is on. I take it that the slave I'm configuring is
> the CURRENT machine. Is this correct?
I don't understand the question. If you are going to use the web start
launch, then you have to connect from the slave's browser. I don't
think it matters otherwise.
> I have started Jenkins on the Windows XP box (using the JRE 6.0 that
> came with Jenkins), defined the node, and got the following error:
What did you start? The following looks like you told the master side
to start it for you, but it is failing.
> Connecting to Old-Build
> ERROR: Unexpected error in launching a slave. This is probably a bug in Jenkins
> java.net.UnknownHostException: Old-Build
Can your master resolve the Old-Build name?
> This keeps repeating every few minutes. My configuration for this node is:
>
> Name Old-Build
> Description Old Build Machine
> # of executors 1
> Remote FS root C:\JenkinsBuild
> Labels WIN32
> Usage Leave this machine for tied jobs
> Launch method Let Jenkins Control this Slave as a Jenkins Servie
> Administrator user name XXXXXXXX
> Password XXXXX
> Availability Keep this slave on line for as much as possible
> Node Properties
> Environment variables (None set)
> Tool Locations (None set)
Here's the troubleshooting page:
http://wiki.jenkins-ci.org/display/JENKINS/Windows+slaves+fail+to+start+via+DCOM
But I'd try changing it to start via jnlp and then launch it manually
from the slave to get started. If you have trouble with name resolution
you can use an IP address in the URL.
--
Les Mikesell
lesmi...@gmail.com
David Weintraub
> On 3/29/2011 7:50 AM, David Weintraub wrote:
>>
>> When I configure another node to create a slave, it doesn't say which
>> machine the slave is on. I take it that the slave I'm configuring is
>> the CURRENT machine. Is this correct?
>
> I don't understand the question. If you are going to use the web start
> launch, then you have to connect from the slave's browser. I don't think it
> matters otherwise.
I go to http://mybuildserver:8080/ in my browser, go to Manage
Jenkins->Manage Nodes->New Node. Now, I'm in the screen where I am
configuring a slave. However, no where in the configuration does it
mention the machine where the slave lives. Where is this slave
located? I take it that this is a slave on machine "mybuildserver". Is
this correct?
>
>> I have started Jenkins on the Windows XP box (using the JRE 6.0 that
>> came with Jenkins), defined the node, and got the following error:
>
> What did you start? The following looks like you told the master side to
> start it for you, but it is failing.
>
>> Connecting to Old-Build
>> ERROR: Unexpected error in launching a slave. This is probably a bug in
>> Jenkins
>> java.net.UnknownHostException: Old-Build
>
> Can your master resolve the Old-Build name?
Does that have to be the name of my machine or the name I give the
node? Does the node name have to be the system name of my slave? Then,
that's my issue.
By the way, my slave will operate on port 8090 (It has CruiseControl
already running on 8080) while my Master will be on port 8080. Will
this be a problem?
--
David Weintraub
qaz...@gmail.com
Les Mikesell
>
>>>
>>> When I configure another node to create a slave, it doesn't say which
>>> machine the slave is on. I take it that the slave I'm configuring is
>>> the CURRENT machine. Is this correct?
>>
>> I don't understand the question. If you are going to use the web start
>> launch, then you have to connect from the slave's browser. I don't think it
>> matters otherwise.
>
> I go to http://mybuildserver:8080/ in my browser, go to Manage
> Jenkins->Manage Nodes->New Node. Now, I'm in the screen where I am
> configuring a slave. However, no where in the configuration does it
> mention the machine where the slave lives. Where is this slave
> located? I take it that this is a slave on machine "mybuildserver". Is
> this correct?
The name of the node is the name you use to connect over the network,
which has to be correct if the master is starting the slave job.
>>
>> Can your master resolve the Old-Build name?
>
> Does that have to be the name of my machine or the name I give the
> node? Does the node name have to be the system name of my slave? Then,
> that's my issue.
Yes, although if you use a windows service or jnlp to start the slave it
wouldn't really matter if the master could resolve the name.
> By the way, my slave will operate on port 8090 (It has CruiseControl
> already running on 8080) while my Master will be on port 8080. Will
> this be a problem?
I think you are still missing something - the slave doesn't run a web
service on a port (or any other Jenkins components), it just connects to
the master even if the master starts it with dcom or ssh. All of your
web interface access is done at the master URL.
--
Les Mikesell
lesmi...@gmail.com
David Weintraub
The trick is that your "Node Name" must match the name of the system
you're using. I don't need Jenkins running on the remote system. I
simply need those particular ports open and accessible. Once I
realized "Node Name" = "Machine Name", it worked.
I also see that I can specify that a job runs on a particular node by
going into the Advanced options when setting up that job.
Thanks.
--
David Weintraub
qaz...@gmail.com
Les Mikesell
> Okay. Now it's clear!
>
> The trick is that your "Node Name" must match the name of the system
> you're using. I don't need Jenkins running on the remote system. I
> simply need those particular ports open and accessible. Once I
> realized "Node Name" = "Machine Name", it worked.
>
> I also see that I can specify that a job runs on a particular node by
> going into the Advanced options when setting up that job.
One more bit of advice: don't tie jobs directly to nodes. Instead give
the node one or more labels that describe the build type capabilities
and specify the required type lable(s) in the job. That way when you
add more nodes and perhaps different types of compilers the jobs will
balance across the set capable of running them.
--
Les Mikesell
lesmi...@gmail.com
David Weintraub
> One more bit of advice: don't tie jobs directly to nodes. Instead give the
> node one or more labels that describe the build type capabilities and
> specify the required type lable(s) in the job. That way when you add more
> nodes and perhaps different types of compilers the jobs will balance across
> the set capable of running them.
This particular job is a one off type of thing. This build requires
JDK1.3 and Weblogic 6.1. The JDK 1.3 won't run on our Linux server
without lots of work. Our Linux server is 64 bits and JDK 1.3 is only
available as 32bit.
The simplest solution was to use our old Windows XP box for the build.
After all, that's where we manually build this app now. The only
reason for this slave is to build this one application.
However, thanks for the information about using labels. I saw that
when I was looking at the configuration.
I'm going to update the Wiki to clarify all of this stuff. My favorite
is the "Step by step guide to set up master and slave machines" which
consists of a two steps and a single snapshot.
One of the things the Jenkins project really, really needs is getting
a tech writer to redo the entire documentation. Jenkins is great, but
our documentation (like many open source projects) is in poor shape.
There's an idea in many open source projects that if you build a Wiki,
the document will come. That only works in the movies.
--
David Weintraub
qaz...@gmail.com
Les Mikesell
>
>> One more bit of advice: don't tie jobs directly to nodes. Instead give the
>> node one or more labels that describe the build type capabilities and
>> specify the required type lable(s) in the job. That way when you add more
>> nodes and perhaps different types of compilers the jobs will balance across
>> the set capable of running them.
>
> This particular job is a one off type of thing. This build requires
> JDK1.3 and Weblogic 6.1. The JDK 1.3 won't run on our Linux server
> without lots of work. Our Linux server is 64 bits and JDK 1.3 is only
> available as 32bit.
>
> The simplest solution was to use our old Windows XP box for the build.
> After all, that's where we manually build this app now. The only
> reason for this slave is to build this one application.
That's the sort of thing you might want to migrate to a virtual machine
before the old hardware breaks. There's a pretty good chance that
VMware's (free) converter tool would migrate the running machine intact
to something that will run under any of the VMware versions, many of
which are also free. But for the things you build more often you might
want a farm of slaves (virtual, physical, or a mix). We do most of our
builds on VM's running under the free version of VMware ESXi, with 4
different guests on each physical server.
--
Les Mikesell
lesmi...@gmail.com
David Weintraub
> That's the sort of thing you might want to migrate to a virtual machine
> before the old hardware breaks. There's a pretty good chance that VMware's
> (free) converter tool would migrate the running machine intact to something
> that will run under any of the VMware versions, many of which are also free.
> But for the things you build more often you might want a farm of slaves
> (virtual, physical, or a mix). We do most of our builds on VM's running
> under the free version of VMware ESXi, with 4 different guests on each
> physical server.
The REAL solution is to stop using obsolete versions of Java that need
specific machines for building. At my last job, I threw a fit that
they were still using JDK1.4. Now, here they're using a version of
Java that has been obsolete for over a decade?
The developers are now working on upgrading their code for JDK 1.6.
and using Weblogic 10.3. That will take a while. Meanwhile, we have
to support our customers while this is taking place.
Builds should be machine independent with well know environments. I
should be able to create a new build system from scratch without
worrying whether we have some sort of specific weird dependency. If I
have to worry about my ability to build and deploy is stuck on some 12
year old system running a version of Windows that's two versions
behind a JDK that was released in 2001, we're doing something wrong.
It's sort of like the "do you check in built objects?" debate. Some
people say "yes" because you don't know for sure whether you can
actually reproduce what you need. Others say "no", and you better
implement a process to make sure you can reproduce what you need. I'm
in the latter category.
Still, you have a point. Until we get this project update to JDK 1.6,
we are dependent upon this particular system whether I like it or not.
--
David Weintraub
qaz...@gmail.com
Les Mikesell
> On Tue, Mar 29, 2011 at 5:08 PM, Les Mikesell<lesmi...@gmail.com> wrote:
>> That's the sort of thing you might want to migrate to a virtual machine
>> before the old hardware breaks. There's a pretty good chance that VMware's
>> (free) converter tool would migrate the running machine intact to something
>> that will run under any of the VMware versions, many of which are also free.
>> But for the things you build more often you might want a farm of slaves
>> (virtual, physical, or a mix). We do most of our builds on VM's running
>> under the free version of VMware ESXi, with 4 different guests on each
>> physical server.
>
> The REAL solution is to stop using obsolete versions of Java that need
> specific machines for building. At my last job, I threw a fit that
> they were still using JDK1.4. Now, here they're using a version of
> Java that has been obsolete for over a decade?
Actually, I'd be sort-of surprised if you couldn't make a 32-bit jdk-1.3
run on a 64-bit Linux if you use RHEL/Centos, etc. that supports both
architectures, and jenkins should let you specify the jvm to use both
per job and its location per node in case you need several different
versions.
> Builds should be machine independent with well know environments. I
> should be able to create a new build system from scratch without
> worrying whether we have some sort of specific weird dependency. If I
> have to worry about my ability to build and deploy is stuck on some 12
> year old system running a version of Windows that's two versions
> behind a JDK that was released in 2001, we're doing something wrong.
Wishful thinking... Like having backwards compatibility so your new jdk
would run your old code without changes.
> It's sort of like the "do you check in built objects?" debate. Some
> people say "yes" because you don't know for sure whether you can
> actually reproduce what you need. Others say "no", and you better
> implement a process to make sure you can reproduce what you need. I'm
> in the latter category.
Everyone here flat out admits they can't reproduce builds so the binary
that passes QA is exactly what runs in production (and I wish Jenkins
had better tools to track/enforce that - without needing maven in the mix).
--
Les Mikesell
lesmi...@gmail.com