4 ms·

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 t

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.

techwizrd 13y ago
I agree. I prefer Ansible because I can get something prototyped and built faster with it and it's easy to refactor a playbook into something more complex and more reusable.
blueskin_ 13y ago
Salt seems a lot simpler to me - Ansible is an improvement over many, but Salt seems to be the same again over it.
- stp-ip 13y ago
  Salt additionally is not opencore, but truly opensource.
  - mpdehaan2 13y ago
    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/ http://www.ansibleworks.com/ansibleworks-awx/
    - secstate 13y ago
      Thanks for the great tool! I think the GUI and REST API a pay-for service was a smart decision and will hopefully allow you guys to keep building out the project while also making a living. Not sure where the confusion about Ansible being not fully opensource comes from. And it's not as though Salt doesn't have enterprise support and tool integration that you can pay for too. As I noted earlier, conf management has so many facets and reasons for being implemented that no one tool will ever win a battle. Honestly I'm happy to have such a wide open space right now with so many great and open source projects in it. When I started developing web apps 10 years ago, there was nothing that begins to approach the robustness of all four big players in this arena right now. Thank you to all the hardworking contributors, paid and unpaid, to Puppet, Chef, Salt and Ansible. Thank you!
acd 13y ago
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 13y ago
  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 13y ago
    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-ansible/ http://blog.ansibleworks.com/2013/12/08/the-origins-of-ansib... http://blog.ansibleworks.com/2013/11/29/ansibles-architecture-beyond-configuration-management/ http://blog.ansibleworks.com/2013/11/29/ansibles-architectur...
    - 13y ago

techwizrd 13y ago

I agree. I prefer Ansible because I can get something prototyped and built faster with it and it's easy to refactor a playbook into something more complex and more reusable.

blueskin_ 13y ago

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

stp-ip 13y ago
Salt additionally is not opencore, but truly opensource.
- mpdehaan2 13y ago
  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/ http://www.ansibleworks.com/ansibleworks-awx/
  - secstate 13y ago
    Thanks for the great tool! I think the GUI and REST API a pay-for service was a smart decision and will hopefully allow you guys to keep building out the project while also making a living. Not sure where the confusion about Ansible being not fully opensource comes from. And it's not as though Salt doesn't have enterprise support and tool integration that you can pay for too. As I noted earlier, conf management has so many facets and reasons for being implemented that no one tool will ever win a battle. Honestly I'm happy to have such a wide open space right now with so many great and open source projects in it. When I started developing web apps 10 years ago, there was nothing that begins to approach the robustness of all four big players in this arena right now. Thank you to all the hardworking contributors, paid and unpaid, to Puppet, Chef, Salt and Ansible. Thank you!

acd 13y ago

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 13y ago
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 13y ago
  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-ansible/ http://blog.ansibleworks.com/2013/12/08/the-origins-of-ansib... http://blog.ansibleworks.com/2013/11/29/ansibles-architecture-beyond-configuration-management/ http://blog.ansibleworks.com/2013/11/29/ansibles-architectur...
  - 13y ago