Second - the management system

So what do you use when you want a management system as a layer over your deployment system?

There are a number of options, but the best place to start (as always) is with a list of requirements. Here are mine:

  • Must have a secure authentication system (SSL if web based, SSH if not)
  • Must detail out who is using the system down to an individual
  • Must have an audit log of all relevant events that happen (espeically launch of a task!)
  • Must be easy to use
  • Must have an interface for running jobs remotely via an API call (covers triggers from CircleCI and the like)
  • Must log all actions at a very granular level, both success and failure
  • Must have a notification system for alerts to one or more of the following:
    • SMS
    • Chat systems (Slack, HipChat, IRC, whatever)
    • email
  • Must be able to run jobs on a periodic basis beyond a manual cron job config
  • Must be able to run from anywhere we need it to (within EC2 for instance)

Sounds like quite the unachievable list without forking out a ton of dosh right? Actually this can be achieved for 'free'.

Each of the main deployment systems out there have a 'paid for option' (prices as I write this in 2014):

  • Ansible Tower
    • Appears to have all the features required
    • Free for 30 days, $99/month/100 nodes or $999/year/100 nodes, minimum 1 year contract per 100 nodes
    • Or, $0.99/month/node or $9.90/year/node, in lots of 100 nodes, minimum 1 year contract per 100 nodes
    • Full pricing info
  • Enterprise Chef
    • Appears to have all the features required
    • Has both a on-premise and a hosted option
    • Free for up to 25 nodes (or 5 hosted nodes), $6/month/node
    • Management console is listed as a premium (i.e. $6/month/node) option
  • Puppet Enterprise
    • Appears to have all the features required
    • Free for up to 10 nodes, starts at $112/year/node, scales down as you have more nodes
  • SaltStack Enterprise
    • Appears to have all the features required
    • Do not disclose prices unlike their competitors - if you have to ask you can't afford it model? No idea myself!

So if you need 'paid for' support, then I would be recommending Ansible just based on price.

The price per node doesn't look too bad. Until you hit bigger numbers of nodes, and watch your budget disappear off into potential support costs. In my experience, if your scripts are working, they are working, so putting that cash into resources (staff or people or whatever you want to call them), is a far better investment to mitigate any potential support issues. Usually you already have those resources available...

Is there a 'free' alternative you ask? Yes.

The system I use to manage my Ansible systems is called Rundeck. Rundeck is made by #SimplifyOps, and they also have a 'Pro' version available that costs money to buy. In the vein of the above:

  • Rundeck Pro
    • Has all the features required
    • Costs $5,000 for a single node, or $7,500 for a HA pair (5k for the first, 2.5k for the second)
    • This equates to the same cost as around 500-750 Ansible Tower nodes per year (500 for single Rundeck server, 750 for HA pair)
    • This equates to the same cost as around 75-100 Enterprise Chef nodes per year
    • This equates to the same cost as around 44-77 Puppet Enterprise nodes per year
    • SaltStack Enterprise don't say publicly...

Rundeck of course doesn't manage Ansible out of the box so to speak, and Ansible Tower does. That said, with minor effort (as I'll explain in later posts) the 'free' version of Rundeck will happily run Ansible jobs and also provide all of the features I needed, just without 24x7 support in the background on the Rundeck (or Ansible) components.

Because Rundeck can run the Ansible jobs (called playbooks) with all of the features above, if you really feel like it, you can give out credentials to specific non-DevOps users to run specific tasks for themselves, with full audit logging both of what the person did, but also the full rundown of each step of the Ansible job in all its glory.

In a later post I'll detail that out a bit more - but next, lets take a look at the Engineers side of things, starting with GitHub...