Is it advisable to run DSL Jobs on Jenkins controller that have over 7000 Jobs.
Jenkins controller isn’t allowed to run builds, just for scheduling jobs on worker nodes etc. There is a request to run some DSL jobs on that controller.
Should we be concern about performance degradation?
Is there any alternative because we don’t want any issue on the controller
What appoach can we adopt if eventually it becomes compulsory that we run the DSL jobs on the controller?
Jenkins version: 2.462.3
The problem with allowing jobs on the controller is that such a job has full read/write access on the jenkins controller home folder, and full access to the processes as well. It is then trivial to decrypt secrets that might be stored there and re-use the credentials to do some damage.
One option could be to run an agent as a separate user on the same host as it will improve security, but in general you want to avoid that.
This can be an issue because there are use cases for performing maintenance tasks on the controller such as managing local git reference clones (they can get corrupted, or bloated), garbage collecting the content of the workspaces folder, etc… The recommended approach would be to write custom plugins to do such tasks, but sometime a simple shell script to run on weekends as a pipeline is good enough.
There might be a plugin to limit the controller’s workers to only some admin jobs, but I’m not aware of one.
One thing to consider is in general that even when a job runs on an agent, a lot of things are actually happening on the controller. Usually only when it comes to interacting with the remote file system or you’re starting processes code is executed on the agent.
So when you run a job that does JobDSL and have it run on an agent what might be executed on the agent is things like checking out the git repo. But most likely all other code from JobDSL plugin is then executed on the controller. It has to run there as it needs to interact with the controller jvm to create/update/delete all the jobs.
Thanks for the contribution. This is helpful. I will research If I could find any plugin that can restrict controller’s workers to run some admin jobs which I think will be helpful in my case if that plugin is out there
I agree with you. That is where my concern stem from because definitely the controller is the one doing the most part of the JobDSL
Job Restrictions can limit that only certain jobs are allowed to run on an agent
Ah great. We use Folders and Folder Auth strategy. All our jobs that so controller level maintenance are under a /System/ folder.
FYI I tested ^System/.* and it works as intended. I tried ^/System/.* and that did not work.