[SOLVED] Can I create a new Jenkins executor node or provide user/password to an existing node?

Can I create a new Jenkins executor node or provide user/password to an existing node?

Jenkins is version 2.414.1.

Users will log in to Jenkins using their LDAP credentials, and manually launch (build) a pipeline job that runs in the built-in (main).

I'd like to execute one (or all) of the pipeline stages in a remote Linux host. Instead of pre-defining a Jenkins node, can I build one on the fly with the pipeline? Or can I reuse a pre-define node, but by providing the user credentials (user scope) so that the node can SSH as the user?

Solution

Instead of pre-defining a Jenkins node, can I build one on the fly with the pipeline?

Yes and no.

If you have a Kubernetes cluster you can set up the Kubernetes plugin. It can spin up the agent pods on demand - probably, it is the closest thing to what you want.

If you don't use Kubernetes, the pipeline expects some free agent to be executed on. So, in theory, you can run it initially on the built-in controller node, run some Groovy scripts to create an agent with a certain label, and use that label for the rest of the pipeline stages. But this would mean the following at the very least:

you're supposed to define where and how an agent will be created (e.g. the node names, SSH keys, prepare all the setup automation);
you will have to approve the potentially dangerous Groovy method signatures to be executed from the user-controlled pipelines;
creation of an agent is a time-consuming task. Of course you could use a pre-built VM image that could be run in minutes, but that implies you already have also some heavy automation along with something like VMware or other hypervisor;
allowing users to access the build nodes imminently leads to the inconsistentencies and configuration drift brought by user interaction. It basically goes against the industry standards (see Infrastructure/Configuration as Code).

Given the list above, I would recommend to think again if you really would want to do this. If you're ready to use the VM-based agents and build the automation around it, there is little to no sense in coupling it with the pipelines themselves. Instead, just create a pool of standardized build agents with strict access policies but available for all the users to use.

With that being said, to achieve the maximum safety and reproducibility for your builds, consider using Docker and running the stages and/or the whole pipelines in containers.