<p>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.</p>

<p>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:</p>

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

<p>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 <strong>only</strong> these two jobs - to run on the master node.</p>

CC BY-SA 3.0
2017-09-22T04:22:05.677Z
2017-09-22T16:36:18.187Z
2017-09-22T16:36:18.187Z
jayhendren
<p><a href="https://wiki.jenkins.io/display/JENKINS/Jenkins+Best+Practices" rel="noreferrer">https://wiki.jenkins.io/display/JENKINS/Jenkins+Best+Practices</a></p>

<blockquote>
  <p>In larger systems, don't build on the master.</p>
  
  <p>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.</p>
</blockquote>

<hr>

<blockquote>
  <p>One master node and no slave node. All their builds run in master
  node. Is this a bad practice?</p>
</blockquote>

<p>Running the jobs on the master nodes means that the jobs have unrestricted access into the JENKINS_HOME directory</p>

<blockquote>
  <p>Are there any bad consequences for having only one master node?</p>
</blockquote>

<p>As the slaves have unrestricted access into the JENKINS_HOME directory this could be unsafe</p>

<blockquote>
  <p>Is my setup (one master &amp; one slave) a bad practice?</p>
</blockquote>

<p>It is better than only one master as long as all the jobs run on the slaves</p>

<hr>

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

CC BY-SA 3.0
2017-09-21T15:56:55.267Z
2017-09-21T16:03:31.670Z
2017-09-21T16:03:31.670Z
030
<p>In <strong>my team</strong> we have one Jenkins server with <strong>one master node &amp; one slave node</strong> in the same server. We use Jenkins Pipelines and surround everything with <code>node{}</code>. </p>

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

<p>Questions:</p>

<ul>
<li>Is this a bad practice?</li>
<li>Are there any bad consequences for having only one master node?</li>
<li>Is my setup (one  master &amp; one slave) a bad practice?</li>
</ul>

<jenkins><architecture>
Is it ok to have a Jenkins Server without slave node?
Oscar Foley
# Is it ok to have a Jenkins Server without slave node?

(Asked by: username_0 on 2017-09-21)

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?

**Tags:** jenkins, architecture


---

## 2 answers

### Answer by username_2 on 2017-09-21. Score: 14 | Accepted answer

<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.


---

### Answer by username_1 on 2017-09-22. Score: 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.


---

