All processes, packaging, configuration, deployments, and so on, requested by the Deployment Automation server are executed on hardware assigned to agents.
Typically, an agent runs on the host where the resources it handles are located. A single agent can handle all resources on its host. If a host has several resources, an agent process is invoked separately for each resource. 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 machine. A deployment to this environment might have one agent and three separate resources.
Agents are an important part of Deployment Automation scalability. By adding more agents, the throughput and capacity of the system increases almost exponentially and so can scale to fit even the largest enterprise.
Depending on the number of hosts in an environment, a deployment might require a large number of agents. Agents are unobtrusive and secure. Once an installed agent has been started, the agent opens a socket connection to the Deployment Automation server. Communication between server and agents uses a JMS-based (Java Message Service) protocol and can be secured using SSL, with optional mutual key-based authentication for each end-point. This communication protocol is stateless and resilient to network outages. The benefits of statelessness are discussed in Agent Communication.
While we characterize an agent as a single process, technically an agent consists of a worker process and a monitor process, as shown in the following figure.
Figure 1. Agent Processes
- The monitor is a service that manages the worker process, for example, starting and stopping and handling restarts, upgrades, and security.
- The worker is a multi-threaded process that performs the actual deployment work after receiving commands from the server.
- Work commands come from plugin steps, which provide seamless integration with many third-party tools.