DevOps tools review for DataCenter automation: Ansible-StackStorm-SaltStack | Hacker News Reader

DevOps tools review for DataCenter automation: Ansible-StackStorm-SaltStack

medium.com

37 pointsanyrekmi21 comments

I've used Puppet, Ansible and Salt. While they get the job done, they all suck in a myriad of ways. They're slow, brittle, have bad documentation (I'm probably being cynical, but Puppet, Ansible and Salt all seem to have been created as consulting companies first and software second; they thrive on the inadequacy of their documentation).

One problem with the "post-Puppet/Chef" generation of tools is the over-reliance of templatized YAML as a DSL. Salt's use of YAML is particularly egregrious. For all the criticisms of Puppet's custom language, at least it's a language, with proper types, a consistent syntax, and a good measure of strictness. I like YAML as configuration file language, but it's terrible for DSLs.

I'm surprised to see this particular criticism applied across the board – Puppet's documentation is one of my favorite things about it.

Admittedly, Puppet's documentation is better than it used to be; I've been using it since 1.x, and it used to be a lot worse. However, it's still a bit tedious to browse through.

The weakest part has always finding reference documentation — that is, things like this [1]. Everything is a bit buried and scattered. At least they finally have a complete list of configuration settings [2] now, which used to be a huge pain.

[1] https://docs.puppet.com/puppet/4.10/types/file.html

[2] https://docs.puppet.com/puppet/4.10/configuration.html

The current version of the Puppet documentation all appears to be for the enterprise product. Our team just evaluated the three and easily found Puppet to have the worst documentation for starting out with the free edition.

Without being a comparison the other tool(s), I would make a point regarding to your blocker, which actually it shouldn't be a blocker.

Many folks miss one important point: Salt's renderer interface is also pluggable. There are quite a few choices for you: https://docs.saltstack.com/en/latest/ref/renderers/index.htm.... For data representation you can choose between: yaml, yamlex, json, json5, hjson, or even pure python. Nothing else can be more flexible than pure python. But, of course, this approach also has its drawbacks. Anyway, if none of them suits your needs for non-terrible DSL, you can even implement your own DSL, your own renderer.

All you have to do is adding few characters at the top of your pillar, i.e. #!json or #!json5 or even #!lobster.

So where is the limitation again? In reading documentation I guess.

The Python interface is the only one that addresses my criticisms, but do people actually use it? Is it well supported, stable and so on?

The YAML is the default, and it's what you find examples and support for (Stack Overflow and so on). I get the impression that many of the renderers are not "official", in the sense that they're maintained by other people.

If Salt only provided a Python API, the situation would be different. As such, it's a case of too much choice, and not enough standardization. There are no less than three competing Python renderers.

I'm not entirely sure I understand you. Do you find it bad that there are several options?

I had the feeling that YAML is the one that addresses your criticism ("I like YAML as configuration file language, but it's terrible for DSLs."). And yes, I do use the python one and I am very happy with it.

> The YAML is the default, and it's what you find examples and support for (Stack Overflow and so on)

Pro tip: if they are YAML on StackOverflow, you don't have to copy-paste them, but more rather translate them to the representation that satisfy your high requirements.

It's a common misconception to read too much into Renderers. Salt's State system takes a data structure as input so each of the Renderer modules is really just what flavor of "data structure generator" you like most.

The so-called highstate data structure is very stable and well documented so Renders rarely need changes:

https://docs.saltstack.com/en/latest/ref/states/highstate.ht...

The regular Python interface you mentioned is my favorite too, when YAML/Jinja aren't a good fit, and people do use it. It's 40 LOC and has only needed 32 commits in the six years it's been around:

https://github.com/saltstack/salt/blob/5406a7cdd4729/salt/re...

The takeaway is YAML/Jinja generate exactly the same result as the Python Renderer so use what you like.

I agree with you (esp. on YAML being a poor base for DSLs), but I've found that Chef has the best documentation out of all of these tools. I used to recommend Ansible as the CM tool of choice but lately I've been digging Chef. Installing agents isn't ideal, but managing control servers isn't a panacea either and Chef can run in solo mode just fine. Additionally, if you use Packer or Terraform/Cobbler/RackHD for managing buildouts, installing and staging Chef isn't that hard; it's actually quite trivial

"If you’re going to skip to the end and see which I declared the winner- you will be disappointed. Consider your requirements and try more than 1 of these products." --- truer words have not been spoken

Regardless of tools, I see two features as essential: agentless clients + programmable dsl. As far as I know, no such tool exists (would love to be proven wrong).

Ansible relies on SSH only, which is pretty much a must on 99,9% servers anyway, but its language (and philosophy) is purely declarative. At the moment you need anything generic, abstracted into functions, you are in trouble. (Believe me, you don't want to be hacking stuff into Yaml, it's a mess).

Chef is the opposite: you have access to a Turing complete language, but you need an overly complex server architecture along with running agents on all nodes.

Merge Ansible's ssh client with Chef's programmable dsl and you probably have something huge there.

Have you tried salt-ssh?

You can use the other renderers in there as well, you don't have to just use yaml.

https://docs.saltstack.com/en/latest/ref/renderers/all/salt....

It exists: https://www.rexify.org

Chef-solo is effectively agentless and is the same thing as installing ansible and running it locally but with a WAY better DSL

I have used Puppet, Ansible, Saltstack and Chef. In the beggining using puppet was annoying because you had to explicitly declare all dependencies or Puppet would do things in the wrong order. This has since the latest versions of Puppet been fixed.

Ansible is good but it has already been forked to Stonic, which for me is a sign of disagreement in the community.

A lot of the management tools tends to have their config agents crashing so you need to baby sit your agents instead of just configuring your servers. I tend to use Puppet, Ansible standalone pulling the configuration templates via git that avoids the crashing agents issue.

I'm a little bit surprised to see StackStorm directly compared to Ansible and SaltStack. There's certainly overlap in capabilities, but in my mental model of the space Ansible and Salt are primarily configuration management, while StackStorm focuses on event-based orchestration.

In my environment we're using both Salt and StackStorm very effectively. Salt for CM and StackStorm as a platform for building automated, event-driven tools. They're really very complementary, especially since both are Python-based.

The overlap of capabilities is between StackStorm and Salt -- the later has many orchestration capabilities. For event driven ops it can even be used alone. I don't want to say that one is better than the other, but this comparison does not surprise me at all.

As a friend (big Ansible fan otherwise) would say: "Ansible is just a glorified bash script; nothing more, nothing else". Without making it a bad product, Ansible is that one limited to CM only.

StackStorm developer here and I definitely am writing this as an engineer. We in fact use ansible for our own infra where we deploy a bunch of StackStorm nodes. Our CI CD pipeline, staging tests and packages promotion all are driven via StackStorm workflows. We also spin new environments on every merge commit to master (results in OS packages which are then deployed to a box) and have built sophisticated automation with StackStorm workflows. Every time I use Ansible, I cannot get over the fact that it is bash in Python. Our API driven approach, chatops, declarative when needed with workflows and ability to be imperative (write python code) for actions etc are things I really love. We are learning from all of the other tools ourselves but I also hope we are setting trends in workflow orchestration.

I have done extensive work with both Salt and Stackstorm, and am surprised they don't see wider uptake, especially Stackstorm. Stackstorm is a brilliant system.

Puppet vs Salt/Ansible is old story, they're compared as applied to config management.

Anthony is bringing a different angle here: how Salt / Ansible / StackStorm compare as event driven frameworks, applied to all-purpose automation, aka GLUE. Puppet/Chef aren't even playing.

Do you see this relevant? Or do you think "Salt beacons, who cares?" Why?

So this isn't a complete picture for complete datacenter automation. you need something that handles server turnup from the minute it's racked and creating images for those servers.

cobbler used to be the go-to tool for provisioning bare metal but rackhd seems to be the new contender in this space. that + packer + terraform + CM = 100% automated DCops

Reply on news.ycombinator.com