First - the fundamental deployment system

05 Dec 2014

To make a good automated deployment system, you need to use something that has a good base to start with, and hopefully something with a bit of community behind it as well. As I write this post in 2014, there are 4 main contenders for the throne of 'best automation system', and based on my own research and experience, I have chosen to go with Ansible.

Who are the four main contenders you say? Here is a really quick summary from my point of view (sorted by name, not by preference) with a view on the 'free' offerings they each provide:

Designed to work in a push capacity (i.e. central server pushes to clients, clients do not typically pull from central server)

Able to be set up in a pull capacity if really desired

Uses SSH with SSH keys to run the vast majority of commands

Can work from anywhere (based on security ACL rules)

Can run as a single server, or if you put the scripts in place with the right commands in them, can run on many servers

Inventory of your servers is something you have to control yourself (although this is easy in AWS with the use of the AWS CLI and ec2.py script as you can dynamically build the inventory as you use the system based on what is actually running)

Uses YAML as the main scripting language, with the backend modules mostly written in Python - you only need to know YAML to create a good Ansible system

While designed to run as a push system similar to Ansible, Salt works on the basis of having a Salt Master and one or more Salt Minions - more complicated, but also more HA out of the box

Can run in a pull capacity, but I've yet to find somebody doing this 'for reals'

Most implementations use a ZeroMQ rather than SSH channel (so custom ports), with the ZeroMQ implementation being faster than SSH

Potentially the best for a locally (and/or distributed) inventory, however requires more configuration and forethought to implement the inventory in a way that won't bite you later on

Based on YAML with Python or other language modules in the background if you need to delve that deeply

So now that we have looked at the 'free' versions, what is the upshot of free vs paid for? In a nutshell if you have more than 10-100 servers, you will either want to pay a ton of money to get the enterprise tools (anywhere from unknown (Salt appears to think as I write this that if you have to ask, you obviously can afford it) to over $100 per node per year), or you will build your own management system.

Yes, paid support can be nice - but in the end if you implement these systems correctly, your issues are usually going to be with something much more entertaining to deal with such as an engineers bad code changes that you are trying to deploy ;)

What did I do? Well I decided 'free' was better than 'paid for' and chose my second system - Rundeck - to cover the missing pieces of basic Ansible without the horrific cost of the Enterprise solutions.