9

In my team we have one Jenkins server with one master node & one slave node in the same server. We use Jenkins Pipelines and surround everything with node{}.

In a colleague's team I have seen that, for some reason, they have one master node and no slave node. All their builds run in master node.

Questions:

  • Is this a bad practice?
  • Are there any bad consequences for having only one master node?
  • Is my setup (one master & one slave) a bad practice?
12

https://wiki.jenkins.io/display/JENKINS/Jenkins+Best+Practices

In larger systems, don't build on the master.

If you have a more complex security setup that allows some users to only configure jobs, but not administer Jenkins, you need to prevent them from running builds on the master node, otherwise they have unrestricted access into the JENKINS_HOME directory. You can do this by setting the executor count to zero. Instead, make sure all jobs run on slaves. This ensures that the jenkins master can scale to support many more jobs, and it also protects builds from modifying potentially sensitive data on $JENKINS_HOME accidentally/maliciously. If you need some jobs to run on the master (e.g. backups of Jenkins itself), use the Job Restrictions Plugin to limit which jobs can be executed there.


One master node and no slave node. All their builds run in master node. Is this a bad practice?

Running the jobs on the master nodes means that the jobs have unrestricted access into the JENKINS_HOME directory

Are there any bad consequences for having only one master node?

As the slaves have unrestricted access into the JENKINS_HOME directory this could be unsafe

Is my setup (one master & one slave) a bad practice?

It is better than only one master as long as all the jobs run on the slaves


In summary, from a security perspective it is a bad practice to run the jobs on the master.

| improve this answer | |
5

There are some situations where running jobs on the master node is fine, but you do have to be careful. Like the other answer mentioned, generally speaking running jobs on the master is bad practice since the jobs aren't sandboxed on the master node.

That being said, sometimes you do want to run jobs on the master node. For instance, two of the jobs on my Jenkins installation are:

  • find jobs whose dependencies have been updated and schedule builds for them against the new versions of the dependencies
  • find open pull requests that haven't been built yet and schedule builds for them

I (as the Jenkins admin) am in total control of these jobs, neither of these particular jobs touch any files on disk (they're essentially "meta" jobs), I want them to be able to run even when all the executor slots on my slaves are busy, and I would prefer these jobs don't block more important jobs in the queue. For these reasons, I allow these two jobs - and only these two jobs - to run on the master node.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.