

Salt stack, the simpler puppet - gcmalloc
http://www.saltstack.com/

======
secstate
Ansible playbooks read about a million times more obviously to me than salt
config files. Probably that's just due to me putting in the effort to learn,
but I think there's a thread of truth in there too. For one thing, Ansible
makes it easy for non-devops folks to just walk through what they'd need to do
to provision a box, and then turn that walk through into an ansible playbook.

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.

~~~
acd
Tango that one, agree Ansible is better to work with.

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.

~~~
stp-ip
With Salt you can now go ssh only ([http://docs.saltstack.com/ref/cli/salt-
ssh.html](http://docs.saltstack.com/ref/cli/salt-ssh.html)) and if speed is of
essence switch to the faster non ssh method (0mq style).

~~~
mpdehaan2
Disclaimer -- Ansible author here.

This isn't exactly an even comparison -- Ansible has been working on it's SSH
implementation for about two years, so it's pretty evolved, and you won't find
that elsewhere. By comparison, Salt's implementation is currently a rough
sketch, and one they discourage using.

Ansible has a pretty robust implementation that allows sudo and su operations,
and is pretty finely tuned for using things like ControlPersist, reports
nicely on when passwords being incorrect, and also has a paramiko
implementation for older EL platforms where ControlPersist is not available.
Doing things like detecting when the SSH-key is not added yet, etc, are also
well handled to lock and be able to ask prompts only when needed, etc.

Ansible also features a higher speed 'accelerated mode' that uses SSH for
secure key exchange, without relying on in-house crypto. Though the new
pipelining features in 1.5 make SSH about as fast as accelerate mode, so
that's saying something!

Anyway, we take security very very seriously, which is why we invest so much
in having a great SSH implementation.

See also:

[http://blog.ansibleworks.com/2013/12/08/the-origins-of-
ansib...](http://blog.ansibleworks.com/2013/12/08/the-origins-of-ansible/)

[http://blog.ansibleworks.com/2013/11/29/ansibles-
architectur...](http://blog.ansibleworks.com/2013/11/29/ansibles-architecture-
beyond-configuration-management/)

~~~
terminalmage
Disclaimer: Salt developer here.

Please don't conflate acknowledging that the ssh implementation is a newly-
implemented feature with "discouraging" the use of it. You're better than
that.

~~~
secstate
I agree that there's no reason to assume that Salt discourages the use of a
feature that clearly required time to implement. But in the docs and videos
I've seen of the new interface the words "way slower" come up over and over
again.

There's a vibe that salt-ssh is an answer to folks who would use Ansible, and
less a feature that Salt has long had on it's list of things that need to be
implemented.

Not saying there's any truth to that statement, but that's the vibe I got from
the folks I know who use Salt and knew that I preferred Ansible at the time.
So while the word "discouraging" is a bit heavy, there's an absence of
leadership as to why salt-ssh was developed and when it's appropriate vs. 0mq.

------
aethr
Their website doesn't make it obvious where to go if you just want to download
salt and get started. It seems to want to steer you towards SaltStack
Enterprise.

However, you can find installation instructions (which include where to
download) for all OSes here:

[http://docs.saltstack.com/topics/installation/index.html](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.

~~~
bsaul
Here :

[http://docs.saltstack.com/topics/tutorials/walkthrough.html](http://docs.saltstack.com/topics/tutorials/walkthrough.html)

And if you're on a mac :

[http://docs.saltstack.com/topics/tutorials/walkthrough_macos...](http://docs.saltstack.com/topics/tutorials/walkthrough_macosx.html)

------
rdtsc
I started looking at ansible but like salt stack better now. Windows support
is one think I liked better about it. I wish I didn't have to deal with
Windows but unfortunately I do and salt has the support for it.

[http://docs.saltstack.com/ref/windows-package-
manager.html](http://docs.saltstack.com/ref/windows-package-manager.html)

~~~
cutie
I have some windows admin work to do as well. However I prefer that ansible
doesn't require daemons on every host, so I was a bit torn on which to use.

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](https://bitbucket.org/mixmastamyk/pave)

~~~
rdtsc
salt has a daemon-less mode as well:

[http://docs.saltstack.com/topics/ssh/](http://docs.saltstack.com/topics/ssh/)

------
njpatel
At Ayatii we use Salt both for initial configuration and scaling. It's very
easy to get setup, and the concepts of States, Pillars and Reactors are easy
enough to grasp and start hacking useful utilities for your deployment.

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.

~~~
stp-ip
njpatel I would love to get my hands on your python code on the reactor stuff.
Still haven't found a real world example for updating loadbalancers or dns.

~~~
njpatel
I was going to do a blog post but never got around to it! I copy-and-pasted
the DNS one we use into a gist (removing specific bits of our setup). We use
DO, but this should get you to a point where all the bits are working and then
you can do as you wish.

Excuse the Python code...I'm very much not a Python guy!
[https://gist.github.com/njpatel/8603816](https://gist.github.com/njpatel/8603816)

~~~
stp-ip
Thanks

------
joaomsa
My main experience is with Puppet, though I have migrated legacy systems from
CFEngine as well. My main gripes with Puppet are that, at times, the DSL is
restrictive and you have to either rely on ugly Execs or dropdown into Ruby
extensions. I can see how this can be off putting to beginners.

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?

~~~
sergiosgc
We switched away from puppet towards Salt. The broad stroked opinion is that
salt covers all of puppet 's use cases, with advantages in terms of both
performance and extensibility.

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:-)

------
VSpike
I started looking at Salt and really liked what I saw, but the first task I
had to do was to provision some Windows Servers on Rackspace or AWS and
configure them. Like the other commenter, I wish I didn't have to deal with
Windows but I'm stuck with it. I found Saltcloud a bit bleeding edge for a
newcomer to configuration management (although improving all the time) with
Windows being its biggest weakness. When it comes to configuration, it also
seemed to me (admittedly with limited experience) the Windows support in Salt
is a poor cousin rather than an equal citizen. Don't get me wrong, it's good
they have it at all, but you'll need to do a lot more work yourself. I plan to
look at Chef next as a possible alternative since the Windows support seems
more mature. No comments on Chef yet so I'd be interested to hear anyone
else's experience with it, especially for a newcomer to config management
tools.

~~~
anentropic
I rather hated the Ruby DSL in Chef... turned me off the idea of DSLs in
general in fact.

I haven't used Saltstack but the use of (jinja-)templated YAML or just plain
Python for state files seems like a big plus.

------
kingrolo
Am loving Salt since switching from Puppet a year or so ago.

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.

------
nathan_f77
We use saltstack at Zenpayroll.com to manage our servers, and I think it works
pretty well. Not 100% sold on the jinja/python stuff, but it does the job.

------
blueskin_
I really want to give Salt a try. I've worked with Puppet and find the syntax
ugly and the logic weird (e.g. all variables are essentially final and can't
be changed in cases after having a value).

~~~
dijit
You'd like chef then, nothing is immutable, everything can be changed on a
case by case basis using #override

~~~
viraptor
But it also results in a mess of what-can-override-what. You can't have just
#override. You've got "automatic", "default", "override" and later added
"force_override" and "force_default", because "override"/"default" were not
enough. And I'm still running into situations (especially when working with
different teams deploying on the same host) where I want to override something
that can't be changed anymore (or doesn't merge the way I need to).

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....](http://docs.opscode.com/essentials_cookbook_attribute_files.html)

~~~
blueskin_
That sounds almost exactly like the current problem I'm grappling with in
Puppet. Variables can be overridden and inherited, except when they can't.

------
dataops_log
Big fan of the speed and simplicity of salt vs puppet. Plus it is multiple
useful tools in one for me (configuration management, system provisioning and
remote execution)

~~~
stp-ip
In my opinion it still lacks more automatic deploy mechanisms. Ansible has
some great ideas, but I guess the time to write your deploy scripts is needed.
I'm still hoping for a salt package like system.
([https://github.com/saltstack-formulas](https://github.com/saltstack-
formulas)) Where you only use your top.sls and perhaps some custom pillar
data, to define how packages interact or where packages are needed. Define
wordpress running on 2 appservers + 1 database node + 1 loadbalancer with ssl
termination and export db and pipe it through gpg via this pillar key. etc. pp

