The operations center provides a mechanism to share agents across client controllers. This works across wide variety of launcher types, including the option to Launch agent by connecting it to the controller.
|
A critical difference between normal inbound agents and inbound agents in operations center concerns how the JVM used to connect to the client controller gets its JVM options.
|
When you configure a shared agent with an inbound agent launcher, the resulting shared agent will show you a Java Web Start launch button.
You’ll now go to a machine you plan to use as an agent, start a browser, access this same page, then click the Launch button to use Java Web Start to start connect the agent. You should see a small GUI window. When the GUI window says "Connected", it indicates that the computer is now under the control of operations center.
The UI in operations center changes to indicate that the shared agent is available to be leased to client controllers:
On supported platforms, this GUI gives you a menu option to install it as a service, enabling it to start automatically upon machine boot-up. You’ll want to do install as a service if you plan to use the computer as an agent permanently.
Installing inbound agent without GUI
If the computer you plan to use as an agent does not have a GUI, you can run the command indicated in the above UI. See the Jenkins Wiki page for a discussion of the same topic.
Bundling multiple inbound agents as shared cloud
When you have multiple identical inbound agents, it becomes tedious to configure shared agents individually. To simplify this, operations center provides "inbound agents" cloud type in the shared cloud setting.
To configure a shared cloud in this manner, select Inbound agents as the cloud type and fill in the details of the inbound agent.
All the inbound agents connected to this share the exact same settings.
When you finish the settings, you’ll see the same Java Web Start launch button as with the inbound shared agent.
The difference here is that you can launch an agent from this button multiple times on different computers, and they are all grouped into one big pool. The "current pool size" section indicates the number of inbound agents that are currently controlled by operations center, including ones that are leased to client controllers.
Inbound agent workflow
Inbound agents work a little differently in operations center compared to stand-alone Jenkins. This section describes those differences.
In stand-alone Jenkins, an inbound client connects to a controller, establishes a channel, becomes an agent, and starts taking orders from the controller to perform builds and other tasks.
In operations center, the same inbound client connects to the operations center and establishes a channel in the exact same manner, but it does not become an agent. Instead, operations center keeps this client idle, until it decides to lease it to a client controller. At that point, operations center orders the inbound client to launch a separate inbound client as a child process, then have it connect to the controller to which the agent was leased.
This new child process connects to a client controller, establishes a channel, becomes an agent, and starts taking orders from this controller, until the lease ends.
One of the implications of this design is that an agent computer must be reachable by all the client controllers to which it might be leased.