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:
- Ansible
- 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
- Chef
- Designed to work in a pull capacity (i.e. new server has to have chef installed locally and will pull info from a central server or servers)
- Can also work in a push capacity (Chef 'Solo') but you lose some of the more centralised capabilities
- Uses custom ports to listen and send commands
- Can run with a single central server, although High Availability (HA) is advised and requires multiple servers and a more complex implementation as a result
- Inventory is usually based on the servers that are reporting in
- The main coding language is Ruby - better than YAML in a few ways, but has a much higher learning curve for the less developer focused Ops people out there
- Puppet
- Also designed to work in a pull capacity
- Also has a push capacity (Puppet Masterless Mode), but again with less functionality
- The main Puppet operator is usually called the Puppet Master - worth noting as thats probably the best IT title out there!
- By default, uses custom ports
- Same view for single (or HA if you do it 'right') central server(s)
- Inventory again usually based on which servers are reporting in
- Also uses Ruby as its main language now - used to use its own language which can still be found in a lot of Puppet implementations
- Salt
- 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.
More on that in the next post...