Pros and Cons of Deployment Agents

Strategies for working “over there”

Deploying software requires getting the software from where it is (an artifact repository) to where it will run in the target environment. Beyond file transfer, there may be additional installation and configuration steps. There are two basic strategies for executing the deployment. You can either have a worker on the deployment target (an agent) or not. Both strategies have the concept of a central deployment server that acts as a controller determining when and how deployments occur.

Agentless Deployments

In an agentless deployment (see Figure 1), the central deployment server is responsible for connecting to the deployment targets and executing the deployment steps, or actions.

The deployment server must log into the target machined when the deployment actions are “on the box.”. On UNIX style-operating systems, SSH is typically used while tools like PSExec are may be used on Windows. Once logged in, the deployment server passes commands to the target machine for execution, may retrieve logs, and takes further action based on the responses.

Other deployments may not require a presence on the box. The middleware being deployed to may supply a remote deployment API, often a web service, to enable remote deployments. In the case of databases, a special URL is required.

Figure 1: Agentless Deployment

Deployments with Agents

The second approach to deployment automation requires the installation of a worker process, an agent, to perform deployments. When the agent is installed on the deployment target (see Figure 2), it provides access to transfer files to, modify files on, and execute commands on the server being deployed to. Agents may also be used to connect to other targets that expose listeners.

Figure 2: Deployments with agents

Deployments that benefit from having direct access to the deployment target simply use an agent on that target. Access through systems like SSH and PSExec are not required.

Deployments to systems like databases and some application servers may not benefit from having a presence on the server may use an agent on the target anyway. Alternatively, a group of utility or “worker” agents may be used to interact with target systems using the same approaches an agentless approach would use.

Advantages of using agents

Simplicity and Ease of Use

An agent is a process that is running on a target server as some user. There is no need to maintain credentials to that machine for connectivity or script connections. Deployment actions are executed as though you are on the machine because your agent is.

Deployment scripts, in the form of plug-ins, are automatically cached on the target server and have their versions managed without any user effort.

Security

Deployments through agents are as secure as, if not more secure than, deployments through other means. Any deployment requires a facility to install or upgrade software on a target. When comparing deployments through listeners such as web services, the usage profile of agented and agentless deployments is similar enough to be wash.

The security issues surrounding SSH and related tools are pretty clear. These facilities are listening for connections, most likely on standard ports. An attacker would expect this tool to be present, and could use off the shelf strategies to attack it.

With an agent that reaches out to its master server for instructions, there are no ports opened on the deployment target to attack the agent. A man in the middle attack (trying to get the agent to connect to a rogue master) is the most likely threat. With IBM UrbanCode Deploy this can be mitigated through a simple exchange of SSL certificates between agent and master. Further, the agent should be installed as a non-root service account so that it is limited to only touching the applications it manages in case the master server is compromised. This is also a best practice to help avoid accidents.

Scalability

Offloading the work of performing a deployment from the Deploy Server to agents reduces the load on that master server allowing a single master to execute deployments that are more concurrent.

Further, in environments with particularly heavy usage, tools that establish a new connection for each deployment can run out of ports if the operating system is too slow to return ports used by terminated connections to the available pool.

Another issue arises when multiple network segments are in use, with firewalls between them. This is very normal when deploying to multiple data centers. In an agentless approach, a firewall exception allowing the master server to connect to each target would need to be requested, approved and configured. In IBM UrbanCode Deploy’s approach with agents, an Agent Relay pair is configured for each network segment. With a couple fast and limited firewall exceptions, networking issues are resolved for the entire network segment in a secure way.

Reliability

If the central deployment server suffers an outage during a deployment, an agentless system will know a command started, but will not know the status. Generally, all deployments that were running at the start of the outage will be considered to have failed with the results of the most recent commands unknown. This is not a good situation to be in.

With agents, each step is ordered as a unit. With the work done by the agent, an outage of the central deployment server has no impact until the step is complete. If the server is down, the agent waits for it to come back, reports the results, passes back the logs, and accepts the next command. If the central servers are configured in a multi-master high availability configuration, the agent is directed to a different master and reports the results without skipping a beat.

Concerns with agents

There are some legitimate concerns around the use of agents. In IBM UrbanCode Deploy we have taken steps to address them.

Installing Agents

Installing something on dozens, hundreds, or thousands of targets is a concern. Even if the installation is easy—and it is—any task multiplied by thousands could be painful. With UrbanCode Deploy, we have made sure that the agent’s installation can be automated.

If SSH is still active on the target host, you can list targets to push the agent to, through the UI, and it will install itself. Alternately, if you have a different automation agent already installed to manage the server infrastructure, the installer is designed to be run headless through automation. We even have a Puppet module and a Script Package for Pure Systems and SmartCloud Orchestrator.

Other customers have used built the built in agent installer steps to expose installing new agents as an UrbanCode Deploy process that can be invoked from within the tool or command line client.

Performance Impacts

Any additional process should be inspected for performance impacts. We have worked hard to keep the agents minimally invasive. They consume a small amount of memory, and nearly no processor power when active. Customers have installed our agents on trading systems where a performance impact of a millisecond could be extremely expensive only after carefully monitoring the agents. The impact of an idle agent is close to zero. A working agent will consume resources as it performs the deployment.

Key Takeaways

• Deployments require some means of acting on a target server, either through listening execution services such as SSH, or an agent.
• Using agents for deployments is generally preferable to the agentless model because it delivers more flexibility, ease of use, and power.
• A system with agents can behave similarly to an agentless tool by using “worker agents”. However, by using several agents, deployment load can be spread out to boost capacity.
• An agent based deployment tool like IBM UrbanCode Deploy can act like an agentless system while an agentless system cannot act like an agent-based tool. UrbanCode Deploy does an especially nice job in this respect by modeling deployment targets (resources) independently of agents.

With an agent-based system, you can take advantage of agents where the benefits outweigh the costs and perform remote deployments the rest of the time. Because modern agent management is very low cost due to automatic install and upgrade facilities, low performance impact, and tight security, agents will be the right choice the vast majority of the time.