I also appreciate that there are a number of ways to set things up in Ansible, which makes it easy to write simple playbooks, and easy to write complex ones with multiple roles and branches as well.
At the end of the day, conf management has so many facets that I've learned to stop arguing the merits of one over another and just accept that there are different strokes for different folks.
The Salt Stack daemons has crashed on me numerous times in production and it bleeps up with iptables firewall rules on firewall rule reload.
I think Ansible template code is much more readable and it does not require maintaining agents on the hosts since Ansible only uses SSH.
That said Salt stack modules are readable and easy and its Python based.
Puppet uses weird ordering which requires lots of dependencies to be declared.
Searched around a bit and found pave. It has the things I need (admittedly straightforward) and is about as simple as it gets. Would be great if it could get some love, as I appreciate the no-nonsense design. https://bitbucket.org/mixmastamyk/pave
For instance, with a couple lines of Python, I was able to 'react' to any new DigitalOcean instance that was created and able to update DNS records or Nginx config (if it was a certain type of instance). As someone is more of a developer than a infrastructure person, Salt saved me a lot of time.
Excuse the Python code...I'm very much not a Python guy! https://gist.github.com/njpatel/8603816
The advantages though once we've gotten comfortable have made our infrastructure smarter and more resilient.
- Idempotency (If you're careful)
- Abstracting configuration data vs methods. Passwords/Keys/Addresses are kept in a Hiera config file and the manifests merely access these variables instead of hardcoding when applying changes.
- PuppetDB as a canonical reference of the state of all our infrastructure. What are all my servers running MySQL? Which version? Where are all my Ceph MDSs?
- Exported resources (also relying on PuppetDB), enabling propagation of information about new nodes to all others. A godsend when paired with Nagios.
Does Salt have anything that matches these use cases?
It is idempotent; there is a central configuration db (a couple of options, actually; we use pillar, a YAML set of files for its simplicity). Exported resources are handled a bit differently (you pull data from servers at config time instead of pushing at export time) but cover the same functionality. The same functionality covers software configuration inventory.
Where it excels is in performance. Our deployment runs on puppet took some 15min, salt handles them in 30s.
I also like its codebase. It is clear and well documented, easy to extend. I am biased towards python instead of Ruby, so take my opinion with a grain of salt (heh:-)
Yes, the run will report on each salt state which can result in either: failed (with a reason), succeeded (with a description what changed), succeeded (nothing changed). Each salt state provided by the project is also intelligent about its use of resources - for example, if you have multiple pkg.installed, the list of available packages will be pulled only once and all states will be able to determine quickly if they need to run.
- Abstracting configuration data vs methods
Methods -> salt states; Configuration data -> grains/pillar. Grains are kind of attributes that belong to a host (like hostname, system version, installed packages, available ips, etc.), while pillar is a plugin system that can provide external data (it can be used like puppetdb too; I've got a plugin that pulls json files from s3 and talks makes it available as a simple hash for example). If you know chef, think attributes/databags (but better).
- PuppetDB as a canonical reference of the state of all our infrastructure.
It doesn't actually provide this out of the box, but provides the needed elements so this is trivial. Basically you can query all your nodes from the salt server (or nodes can query each other). You just need to extract the bits you need and save them to whatever destination you want. For example on the server run `salt -G 'roles:database' grains.item mem_total` and save the data. You can also define a "returner" which is a plugin that handles the data you get back and for example implement something that writes the data back into your information store/cmdb.
- Exported resources (also relying on PuppetDB), enabling propagation of information about new nodes to all others.
Pillar again. Although depending on what you want to achieve, you may want to enable some querying between the nodes, so that one of them can just broadcast some message at runtime and work on results.
This is one of the most annoying parts of chef for me. And it is quite complex: http://docs.opscode.com/essentials_cookbook_attribute_files....
However, you can find installation instructions (which include where to download) for all OSes here:
http://docs.saltstack.com/topics/installation/index.html
I have yet to check Salt out, but as someone who's just come off the back of Puppet's steep learning curve and lack of robust modules, it's something I'd like to look into.
I haven't used Saltstack but the use of (jinja-)templated YAML or just plain Python for state files seems like a big plus.
In conjunction with Salt Cloud I type a one liner to spin up a new Linode, battle harden it, and install my stack on it.
They've also recently added some states for supporting docker containers which looks interesting.
