I'm starting to work with Jenkins , I'm a newbie, and I have a question regarding Master-slave configuration. How's usually used? Is it one slave per application (i.e: 3 applications, 3 slaves)?
PS: If you point me to a good Jenkins tutorial, will be appreciate it
First, my recommendation is to disable all the executors on the master and to build only on slaves.
On our Jenkins platform, we are using 7 CentOS slaves (VM) for the Maven builds (one executor per node).
These slaves have the same Jenkins label ("build linux" for example).
All the Maven projects are restricted to this "build linux" label:
https://serverfault.com/questions/359793/tell-jenkins-to-run-a-specific-project-on-a-particular-slave-node
We also have dedicated slaves per platform (Linux 32bits, Linux 64bits, AIX 6, AIX 7, Windows 2008 R2, Windows 2012).
If you need to deploy your applications on dedicated Application Servers (Tomcat, Weblogic, ...), you can create one slave per platform.
Using Jenkins label is really useful to distribute your builds on the relevant slaves.
First recommendation is to use at least one slave and not use the master for building.
Read https://wiki.jenkins-ci.org/display/JENKINS/Distributed+builds (first answer when googling "jenkins master slave tutorial").
Then, add as much slaves as you want to distribute the load. The load does not directly depends on the number of "applications" but on the number of simultaneous builds and available slaves to perform those builds (you may have multiple jobs for a unique application). Typically, you will add slaves if your builds are "pending" for too much time: see https://wiki.jenkins-ci.org/display/JENKINS/Executor+Starvation
Tie the jobs to labels rather than directly to the slaves.
You will obviously have different slaves per build environment.
If your build is isolated enough and it is not multi-threaded, then it is also recommended to set about as much executors as core CPU. That is to make use of the slave resources; another solution is to use virtualization, containers (VM, docker...) as slaves with one executor per slave.
Related
I'm tyring to figure out the best strategy for containerizing builds in a Jenkins CI/CD infrastructure using Docker. From what I see I have 2 options:
(1) Use ephemeral slaves that get provisioned on-demand on Docker hosts using the Docker Plugin: https://wiki.jenkins-ci.org/display/JENKINS/Docker+Plugin
Once the build completes the slave is disposed. As a consequence, only one build ever gets run on a single slave.
(2) Use static slaves (e.g. VMs) that run builds inside Docker containers using the CloudBees Docker Custom Build Environment Plugin: https://wiki.jenkins-ci.org/display/JENKINS/CloudBees+Docker+Custom+Build+Environment+Plugin As a consequence, multiple (isolated) builds can run on a single slave.
What are the main advantages/disadvantages of one approach over the other? When and why should should I choose one over the other? This does not appear at all obvious to me.
I suspect builds are lighter weight that slaves, so for a CI/CD infrastructure orchestrating a large end-to-end pipeline with many jobs running (2) would be more scalable - each Jenkins slave incurs at least 2 threads on the master node.
Edit
My preference is the option 1 (ephemeral slaves) with the Docker plugin.
With this plugin, you declare your build images in the global Jenkins settings, you can affect labels to your Docker images:
On your job, you just have to use the relevant labels, and the Docker plugin will create the relevant slave into a new container.
With the Docker plugin, Jenkins will spin-up a new slave in a few seconds. So even if you're using a pipeline with a lot of stages, it will work fine.
This is what I'm going to implement at Forgerock (my company):
2 powerful bare metal machines (with SSD, 32 cores and 1 TB of RAM)
The Jenkins Docker plugin
Maven artifacts caching using Artifactory (to not download the internet)
The docker container will use a local Maven cache (so I'm sure to not use an old/odd Maven artefact)
I did a POC on a small bare metal machine and it works well :)
If you are using ephemeral slaves without Maven caching, it can become a problem regarding the performance.
Regarding the Jenkins plugins, there is a new one developed by Nicolas De Loof: Docker Slaves plugin.
I have to try this new plugin.
I would like to raise from scratch a build server for .NET applications using Jenkins, please note that i'm new to Jenkins CI.
Several Questions:
1) How should I decide on the build server specs? except for the OS which would be windows server 2012, how should I decide on the RAM and the CPU and HD space?
2) Should the Jenkins sit in the build machine or not, what is the recommended approach? I understood that the build server should be isolated from the Jenkins master
3) How do I decide on the Master/Slave approach, when should I use only Master and when should I use master and slave or slaves?
4) How would you recommend me to run the build and deployment tasks in the Jenkins CI, using NAnt/Python or any other scripting language ?
10x, and sorry for the igonrance :)
Responding to each in turn:
You can run Jenkins as a windows service (instructions here) and the machine can be a VM, so it doesn't have to be huge.
a) RAM and CPU: I'll put these together and will depend on how many jobs you plan to have running at the same time. The default number of build executors is 3 but can be increased as a global config change.
b) HDD: This depends on how many jobs you plan to have. Jenkins will checkout the source code (as well as the compiled output) to its home directory on a per job basis. This can get big. I would also recommend using the ThinBackup plugin to backup the Jenkins configuration.
Jenkins is the build machine. A vanilla installation of Jenkins is the master. In my experience you will not need a separate slave machine unless you're needing to do native builds on other platforms or have LOTS and LOTS of jobs. I've seen single masters running happily with hundreds of jobs.
Further to 2. above, suggest you start with a master and set up a slave later if you really need one.
As you have stated you are building .NET applications, you can simply install the MSBuild plugin which should serve you well. Builds for .NET applications in Jenkins are Freestyle builds so you will be using Windows Batch build steps often as well. This also is a great blog on Jenkins in a .NET environment.
I am trying to scale Jenkins for a large organization. Is there a way to have multiple Jenkins masters share a slave pool? For example, if I had 200 Jenkins Masters and I want them to share the same set of 50 Linux slaves.
That is, assuming each slave only has 1 executor, if Master A submits a job to the slave pool and it is running on Slave 1, if Master B submits a job to the slave pool, it would try to run on one of the other free slaves, since Slave 1 is already occupied.
I know multiple masters could share a single slave if I configured the slave to have a new workspace and executor for each master. However, I want to be able to set the slave up once, instead of having a slave.jar running on the slave for each master.
Cloudbees Op Center appears to provide this functionality, but looking for a way to do this with the Open Source version. If not, how difficult do you think it would be to extend Jenkins to have this functionality? I have Java development experience and have done a little work with Jenkins plugin development.
Thanks,
As you've noted it's not hard to share slaves between masters, just setup multiple workspaces and each master will install it's own slave jar. The trick is to share resources properly.
One such resource manager is Apache Mesos. A Jenkins Mesos plugin exists enabling the creation of slaves on a managed cluster.
This approach is very new and Ebay have blogged on how they've evolved their Jenkins setup to use Mesos:
Ebay CI solutin part 1
Ebay CI solution part 2
Hope this helps.
There is a Gearman Plugin developed by Open Stack to handle sharing slaves by multiple masters.
If it were me, I'd set up all the masters with a cloud plugin for slaves. For example, you could install the kubernetes plugin or the nomad plugin and connect all masters up to the same kubernetes or nomad cluster. Nomad or Kubernetes would take care of resource management, and the masters would only be submitting jobs to a shared pool of resources. This concept can easily be applied to other cloud providers, like AWS, but IMHO if you just want to set up an on-prem pool of resources for your jenkins masters from scratch, nomad is the easiest option.
I'm new to Jenkins and Continous Integration, and I noticed that it supports master / slave nodes. I really don't know what that means.
Can someone please tell in what scenario do I need slave agent?
Here is a scenario:
Our main Jenkins master is running on Windows machine (yes I know... I know...). We are doing iOS mobile development. There are some things that can only be done using Xcode (which only runs on Mac OS). I have a Jenkins Slave running on that Mac, that takes care of executing those tasks that can only run on a Mac.
Why not just setup a new instance on that Mac? Cause that job is tied together with other jobs (on Master) in dependencies and the flow. Even promotions on those Xcode tasks are run on Master.
Jenkins' Master / Slave architecture is used to manage distributed builds.
There are many different scenarios you might want to use a distributed build system. It is all based on your projects load and dependencies.
Pretty much, the Master is what you're probably currently using, and is responsible for scheduling builds, dispatching jobs to slaves, and monitoring the results, but can also execute jobs itself. A slave is a java executable that sits on a remote server waiting for instructions from the master (to execute build).
To use this functionality in Jenkins, go to "Manage Jenkins" screen, and click on "Manage Nodes"
https://wiki.jenkins-ci.org/display/JENKINS/Distributed+builds
For a more in depth summary of distributed builds with Jenkins, as well as some scenarios where this system would be useful, and how to implement it, please read chapter 11: Distributed Builds of Jenkins: The Definitive Guide by John Ferguson Smart
http://wakaleo.com/books/jenkins-the-definitive-guide/download-jtdg-pdf
I am using Jenkins for CI,
I've heard that I should have a dedicated server and slave for running Jenkins and building tasks, respectively -
is this true?
I can understand this as the server may not be powerful enough to handle the server itself and running build tasks,
but is there any defined technical reason for this?
Best practice is to have a separate machine for Jenkins-Server,
and not to use it for builds at all.
This has nothing to do with CPU-power or memory-resources -
A build-machine should have a predefined configuration,
and Jenkins should not be part of it.
(Jenkins requirements may even conflict with those of the build-machine)
You should be able to boot / clone / upgrade / restore / trash the build-machine
without any impact on Jenkins.
Of course you can settle for a single machine, if your resources are limited,
but if you are serious about build-automation - Jenkins should have its own server.
You probably don't need dedicated hardware/VM to run a Jenkins server because the actual Jenkins process (no builds running) uses very little resources. But it all depends on what you want to accomplish with your Jenkins setup.
Do you want to run continuous builds across multiple platforms for multiple projects? Then using a master with slaves is the only way to go. If, on the other hand, you're running fairly simple builds for just a few projects, then you only need one machine to run the builds and the Jenkins process.
You can configure Jenkins to have multiple builds running concurrently so if you have a quad-core machine, you can safely run 2 builds and possibly a third once you analyze resource usage.
At my last gig, I used a quad-core machine with 8GB RAM to run:
Jenkins running Selenium builds
VirtualBox VM with Windows XP
Two instances of Tomcat each with two applications deployed.
And the machine still had more to spare.