I can start Jenkins agents with syntax like this:

java -jar agent.jar -jnlpUrl http://hostname:8080/jenkins/computer/<agent_name>/slave-agent.jnlp -secret 12345 -workDir "/jenkins"

This is the pattern for launching a "permanent agent" - when I have specific machines I want to use as agents. It relies on me knowing in advance what each of the agents is, but is there a pattern that I can use when I don't know in advance what machines will be available?

I can't run the script above on multiple hosts: Jenkins requires each agent's name to be unique. You cannot have two agents with the same name, and even if I used the hostname as the agent name, I would need to have defined it in advance before attempting to launch the agent.

Here's my situation:

I want to reuse some machines on the company network as a low-spec "cloud". I want them to be able to run a script from a shared folder which just adds them onto the Jenkins system. I don't know which machines will be available in advance, and I don't want to write new configurations for each machine. And I want to make it so that it's up to whoever owns the machine whether the machine is part of Jenkins, so that means I can't use SSH-style launching.

I see that Jenkins has options for "clouds", but these all seem to be way more complex than what I need. I don't want to have to use any particular cloud infrastructure. I don't want to give the Jenkins master any special cloud credentials.

Is there a way to configure a very simple "cloud" of agents such that I can run a script on each machine, and it just gets added to Jenkins?

I know there are plugins for all kinds of cloud infrastructure, but they all seem to depend on specific cloud infrastructure providers (e.g. Amazon, DigitalOcean). I don't want to get into that - this is a much more casual affair!

So is there a way to do this? It's a low-effort, minimal-configration, ultra-generic cloud in Jenkins where I can run launch-scripts on an arbitrary collection of machines and have them just work?

CodePudding user response：

There is a very nice option to solve your situation by using the Jenkins Swarm Plugin:

The Swarm plugin enables nodes to join a nearby Jenkins controller, thereby forming an ad-hoc cluster. This plugin makes it easier to scale a Jenkins cluster by spinning up and tearing down new agents, enabling team members to contribute compute resources to a build farm or to attach agents to which the Jenkins controller cannot initiate connections.

This plugin consists of two pieces:

1. A self-contained client that can join an existing Jenkins controller.
2. A plugin that needs to be installed on the Jenkins controller to accept Swarm clients.

This is not actually a cloud solution (although can be used with cloud agents) but rather and option to use a reverse approach - meaning you don't connect to the slaves from the Jenkins controller, the agents connect themselves to the controller.
Each connecting agent creates a unique Node in the controller according to the configured parameters it was executed with (label, environment variables and so), thus forming a swarm of agents connected to the controller and available for builds.

Activating the swarm only requires to run a small java app on the agent that wants to connect, and the app can be terminated at any moment by the user - causing the agent to delete itself from the Jenkins controller and exit the swarm.
In addition there are many configuration options to configure the different Node configuration which the agents will be using when connecting to the controller.

This should satisfy most of your reequipments, you can create a simple shared script for running the swarm client and then just run it from whatever computer (linux, windows, mac, any VM) that wants to join the Swarm, while all you need is Java installed.

We where using this plugin successfully for a similar case in which we wanted to add additional nodes when needed based on some monitoring event, and the flexibility of the plugin allowed us to play with the Swarm option in many useful ways.