Live data from Hacker News

Salt stack, the simpler puppet

saltstack.com

21–30 of 34 posts

Re: Salt stack, the simpler puppet

#21
post #15

Earlier quoted context omitted.

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

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…

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.

Re: Salt stack, the simpler puppet

#22
post #5

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…

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.

Re: Salt stack, the simpler puppet

#23
post #22
post #5

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…

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 wei…

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

Re: Salt stack, the simpler puppet

#24
post #5

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…

Salt seems a lot simpler to me - Ansible is an improvement over many, but Salt seems to be the same again over it.

Salt additionally is not opencore, but truly opensource.

Re: Salt stack, the simpler puppet

#25
post #9

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 in…

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.

Re: Salt stack, the simpler puppet

#26

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)

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

Re: Salt stack, the simpler puppet

#27
post #4
post #2

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

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

salt has a daemon-less mode as well:

http://docs.saltstack.com/topics/ssh/

Re: Salt stack, the simpler puppet

#28
post #23
post #22

Earlier quoted context omitted.

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 wei…

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

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/11/29/ansibles-architectur...

Re: Salt stack, the simpler puppet

#29
post #24

Earlier quoted context omitted.

Salt seems a lot simpler to me - Ansible is an improvement over many, but Salt seems to be the same again over it.

Salt additionally is not opencore, but truly opensource.

Ansible is open source.

We do have a GUI/REST-API company product that sits on top of Ansible that adds things like role based access control, centralized logging, and so on. This is not an enterprise version of Ansible, but an additional offering.

By making this commercial we can produce a really high quality product by hiring some top notch developers, and can move forward at a faster pace.

There are no proprietary modules for Ansible that we hold back, but enterprise companies do have more stringent requirements for tools and that's where we draw the line.

For many users, Ansible will continue to be all they need, and that's fine with us too!.

For reference, here's information about our commercial product:

http://www.ansibleworks.com/ansibleworks-awx/

Re: Salt stack, the simpler puppet

#30
post #23

Earlier quoted context omitted.

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

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…

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.

Post reply on HN