Why agent based software deployment engines are better then agent-less


Leroy was created based on over 10 years of experience using different software deployment automation tools. The very earliest version of Leroy was SSH based and completely agent-less. After using leroy in this way for a few years, some limitations were realized with this method:

  • My deployment is at the mercy of the version of SSHd installed on my host and how the system has its security configured for ssh connections.
  • I can not securely connect as root.
  • I can’t easily update my version of sshd on all platforms from my deployment.
  • Windows doesn’t support ssh by default and requires special software and configurations to use it. Moreover, I can’t automatically install this software with my deployment engine.
  • I am unable to disable ssh on my host and still allow deployments.
  • I don’t have a controlled operating environment with a common scripting language.
  • Old versions of SSH will open door to script kitty hackers. New versions becomes old versions quickly.
  • If someone hijacks one of your hosts they just need to sit and wait until you send them the private key / password. Maybe this is the same key / password as your other hosts ? Maybe not ? Shall we chance it ?
  • If all my hosts are agent-less ssh based, then I must create a network policy to allow my deployment server to connect to each host in each environment. This also causes me to have an additional listening port to manage on each of my hosts. This is less then ideal in high security production environments.

What’s the answer ?
Use a secured agent !

Leroy uses a secure agent that trusts the controller. Should a host be hacked where an agent resides, all the hacker will reveal is the ip address and port of the controller which under normal circumstances is not listening. The controller only listens on its TCP port when a deployment is happening. Agents poll for this ip/port in the background waiting for it to come online.

This also creates a very expected connection situation for the controller. We also know what version our agents are and we have the ability to update them. Additionally, by having an agent we can also embed a powerful and common python scripting language which works on almost all platforms. Along with python, we include common functions needed for deployment automation, such as checking if a port is still listening, or has started listening, or polling a url to see if a string exists. If we choose to continue to use agent-less, these doors would not be opened to us. Leroy agents can be run as root, if desired. The agent does not listen on any ports and offers no tangible security concerns.

The Leroy agent has no significant overhead. It does not require, nor want a java run-time environment, or any run-time environment since the agent is a simple compiled binary and uses about 4 Meg of ram. Another important reason for an agent is that different operating systems act very differently when dealing with even the most simplest things like transferring and writing files to disk, and executing commands. Without a tight hold of the OS from a C++ perspective some tweaking may be nearly impossible to deal with using an agent-less model.

We can not prevent a mix of different operating systems in our computing environment these days. I am sure that Red Hat has Microsoft windows servers in their organization that they heavily depend on, as well as Microsoft has linux they depend on as well. Some companies, especially government contractors can not get away from things like AIX and Irix. True deployment automation needs to support as much of these¬†platforms as possible. When dealing with so many, it makes more sense to write a standard all platforms can use, rather then changing myself to support all the differences I want to be able to inter-operate with as many different systems as possible by communicating with them using the most common of computing languages… machine language.

Leroy is available for download at: http://www.leroydeploy.com/download/

Leave a Reply