Agents
An agent is a lightweight process that runs on a deployment-target host and communicates with the IBM® UrbanCode® Deploy server.
There are two agent types. Web agents use WebSocket connections and HTTP(S) for agent-server communication. Web agents were introduced with version 7.0.0. Agents delivered before version 7.0.0 are called JMS agents. JMS agent use JMS and HTTP(S) to communicate with the server. You determine agent type when you install the agent.
Agents do the actual work of deploying components and so relieve the server from the task, making large deployments that involve thousands of targets possible. Usually, an agent runs on the same host on which the resources it handles are located. A single agent can handle all the resources on its host. If a host has several resources, an agent process is started separately for each one. Depending on the number of hosts in an environment, a deployment might require many agents. For example, a test environment might contain a single web server, a single middleware server, and a single database server all running on the same host. A deployment to this environment might have one agent and three separate resources.
Agents have one or more matching agent resources, which represent the agents in the resource tree.
Agents are installed with the batch files that are provided with the installation files, see Installing agents from the command line. You can install agents on UNIX™ systems with the web application. Agents are run with the batch files that are included with the installation package.
Agents are unobtrusive and secure. Agent communications use SSL encryption and mutual key-based authentication for server-agent communication and employ JMS, HTTP, and HTTPS protocols to communicate with the server. See Agent security and communication.
Agent configuration consists of assigning an agent to at least one environment; agents can be assigned to multiple environments. If an agent is assigned to several environments, it can do work on behalf of all of them.
To manage agents, see Agents and agent relay configuration.
Agent prototypes
An agent prototype is a resource that represents one or more agents that are not yet installed or connected to an environment. You can use agent prototypes in resource templates to represent resources that are not yet available. When you import a resource template from the cloud, an agent prototype is created for each node in the cloud pattern.If you create a resource template instead
of importing a resource template from the cloud, you can specify an Agent Name
Pattern for any agent prototype that you add to the resource template. The agent name
pattern can include the properties ${p:application.name}
and
${p:environment.name}
, but no other properties or wildcards.
Agent IDs
Each agent has a uniqueuuid
that is created
the first time you run an agent and is connected to the IBM UrbanCode Deploy server. You can obtain agent uuid
from the Agents page by
selecting an agent. It is managed on the server. There is a one-to-one relationship between an agent
name and its uuid
. You can use either agent name or its uuid
to
delete an agent.
Along with an agent's uuid
, an agent has an endpoint ID that is generated as
part of an agent installation process. An agent's endpoint ID is found in
conf/agent/installed.properties file of your agent install directory with the
property name locked/agent.id. This endpoint ID is broadcast to the server when
the agent connects and is used by the server to uniquely identify any given agent. When an agent is
restarted and connects back to the IBM UrbanCode Deploy server, the IBM UrbanCode Deploy server identifies the connecting agent by its endpoint ID and matches it up with the agent
uuid
.
You must use the server-side generated agent uuid
only
while managing an agent as it is more accessible than the agent's endpoint ID which is never
intended to be seen by end-users.