Ranger4 DevOps Blog

Agents: to be or not to be in IBM UrbanCode

Posted by Helen Beal on Tue, Apr 29, 2014 @ 10:04 AM

If you're thinking about using an Application Release Automation tool, like IBM UrbanCode, one of the things to consider during your evaluation of the solutions available is how you want to, or don't want to, use agents. While you're thinking about this, you'll want have three key aspects of your implementation uppermost in your mind:

  1. Security
  2. Scalability
  3. Simplicity

The IBM UrbanCode architecture is designed in multiple parts:

Service Tier:
The controller server or servers, sit in the controlling service tier. They provide the UI, workflow engine and security services. Users log into the service via web GUI or CLI to configure the tool, run deployments and view reports. The controllers have little state; if one fails another load balanced controller can take over seamlessly.

Data Tier:
Configuration for UrbanCode Deploy is stored in a back-end database (several database vendors are supported). Flat files, including deployable artifacts and logs, are stored in a storage system known as CodeStation which is typically backed by network storage.

Agents:
Work done on a remote target to help a deployment or import new versions is performed by agents - agents are small processes that do work on behalf of the controller servers. Deployment activities including moving files, adjusting configuration, starting and stopping, interacting with load balancers, and interacting with ALM and ITSM tools are performed by agents.

An agent is a light-weight, stateless, Java process running on a remote server. It subscribes to JMS topics provided by the controller server and when the controller puts out a task for it to run, the agent picks up the task and runs the appropriate commands. It utilizes web services provided by the controllers to obtain additional information it needs or post back results as necessary.

Agent Relays:
Agent Relays are proxies/brokers that consolidate traffic from multiple agents - they streamline firewall configuration and reduce the load on the controllers.

A common challenge with multiple data-centers is that firewalls exist between data centers or network segments. Enabling server-agent communication requires either broad firewall exceptions or many exceptions. The Agent Relay helps alleviate these challenges by consolidating Agent traffic. Relays may be installed in groups to provide high availability.

Agentless Deploys

If you choose not to use agents, you'll need to use some sort of service to communicate with your deployment targets - in the world of Linux this is usually SSH (Secure SHell) and in the Windows world, WinRM (Windows Remote Management). Both of these services open up a port and listen for incoming connections.

The process initiation and stream handling is done on the server and there may be a limit to the volume of concurrent processes the server can handle at any one point in time. Also, 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.

You may already have SSH or WinRM running, in which case your setup overheads will be nice and low. If not, you'll need to visit each target and enable and configure the connection services.

Agent Based Deploys

In this scenario, an agent is deployed on the target environment where it runs a process. The agent based process does not listen for incoming connections - the process itself initiates a connection with the server. This means that any security implications around having a port listening are moved to the deployment server rather than being on the target application itself. This makes this approach much more secure; you still have the benefit of SSL encryted traffic and mutual end-point authentication as with agentless SSH based deploys but you don't listen for incoming connections - there aren't open ports on the application servers.

With an agent based setup, the process initiation and stream handling is handled at the agent, markedly improving scalability and mitigating risk when network fidelity or performance is compromised. With agents, because each step is ordered as a unit and the work is 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.

With UrbanCode, if you already have SSH/WinRM set up, you can use this to deploy your agents swiftly and easily. If not, you'll still need to visit every end-point to do this or install and configure your agents - there isn't much difference between these two approaches.

Alternately, if you have a different automation agent already installed to manage your server infrastructure, the installer is designed to be run headless through automation. UrbanCode also has a Puppet module and a script package for PureSystems and SmartCloud Orchestrator.

Some organisations we talk with raise concern about potential performance impacts on their applications but the UrbanCode developers architected, design and built their agents to be minimally invasive. They only consume a minute amount of memory and virtually no processor power when active and the impact of an idle agent is close to zero. A working agent will consume a tiny amount of resources as it performs the deployment - a small price to pay for the increases in volume, frequency and consistency of releases an ARA tool brings.

Agent Relays

Some of our customers' policies/preferences are averse to having agents on the production services, but the increased security, scalability and robustness of an agent based architecture appeals. Installing an agent on an intermediate box, an agent relay (or proxy, broker or worker agents) may be the best solution.

SUMMARY LEARNINGS

  • Deployments require some means of acting on a target server, either through listening execution services such as SSH, or an agent
  • The agent based approach is often preferred because it is more secure, scalable and robust and has very little additional setup overhead
  • A system with agents can behave similarly to an agentless tool by using proxy agents. Using several agents boosts capacity by spreading load
  • Agent based deployment tools like IBM UrbanCode Deploy can act like agentless systems but an agentless system cannot act like an agent-based tool
  • IBM UrbanCode's architecture is designed to scale to meet enterprise requirements: high availability, horizontal scalability, quick response and tight security

 

     

Topics: Agents, UrbanCode, application release automation