3 ms·
I've used and continue to use, both. I like both tools, it's hard to choose one. Ansible advantages: +1 no client required. Python libraries may be required o
by maheart 13y ago
I've used and continue to use, both. I like both tools, it's hard to choose one.
Ansible advantages:
+1 no client required. Python libraries may be required on the client machine to take advantage of certain modules (e.g. Python's postgresql library to use some parts of the postgresql module)
+1 roles. A nice, best practice way to package up logical configurations (e.g. files, templates, tasks).
+1 separate host files for prod/uat/dev/whatever you like. Keep all generic configuration tasks/roles host-agnostic.
+1 very easy to write (and distribute) additional modules
+1 uses SSH for all transport. I love that it uses something tried and true, secure, and robust like SSH. Based on comments on Salt's Github, Salt may be receiving something similar soon. A ZeroMQ mode (aka Fireball mode) is available in Ansible for speed.
+1 sticks to Linux (Unix?) only. I like that Ansible is not targeting Windows (for now?); The Windows ecosystem is a very different community; with its own mindset and tools, and they'd prefer to use their own vs. something from Linux-land. This also allows Ansible to concentrate on getting really good on Linux/Unix.
Salt stack advantages:
+1 (+1 +1 +1) allows you to use Python (with Jinja2 templates) to express logic in configurations. Some people are against this (and tools like Puppet and Ansible try to hide programming from the user), but I feel this is a terrible idea. All that you end up doing is writing a configuration language that's Turing complete [joking!]). Some people will say: logic doesn't belong in configuration! But when you need to express conditions or loops, let me use a (standard, i.e. Python) programming language. I don't want to have to learn your DSL (which only your specific community knows about).
So in summary, I'd love a tool, that has:
- Ansible's "no client" setup
- Ansible's logical way to package up configurations (roles)
- Ansible's separate host file setup
- Ansible's simplicity of writing (and distributing) modules
- uses SSH (currently only Ansible, but might be available in Salt shortly)
- Salt's templating being available in Salt states (Ansible's "playbooks"). This point alone puts Salt on even ground with Ansible. I cannot stress this point enough. This is the reason one of the main reasons I don't use Puppet and Chef.
- mpdehaan2 13y agoAs for logic, to me, it's important that the language remain a data format and be parseable and auditable, i.e. "human readable for non programmers". We had one manager describe it as "automation even a manager can understand". I'm a developer, but I'm jaded about software development, and I definitely agree with the approach Ansible (and Puppet) take about describing infrastructure with a model, rather than making it a program. I'm not really even trying to make it turing complete, I want to create a language that allows modelling how you want to describe the datacenter, but it's not trying to be a programming language. In fact, I'm rebelling against it trying. There's a difference to a developer vs sysadmin mindset, but as something in between, I want to write applications code when I'm writing code, rather than writing infrastructure automation code. Code should be minimized, and that makes things more reliable in the long run, and enforces consistency IMHO. I'm a little unclear about what you say about putting host specific information in Ansible roles. Pretty sure you can't do that, but I may be misunderstanding the question :)
- maheart 13y agoHi Michael, thanks for all your work. About the second point (host specific information in Ansible roles): I was referring to this: http://www.ansibleworks.com/docs/playbooks.html#roles http://www.ansibleworks.com/docs/playbooks.html#roles -- I was (incorrectly) under the assumption that you could put host file variable overrides (as you would in host_vars) under the vars/ section, but it looks like that's more of a generic, non-host, non-group specific variable directory? I have edited my comment and removed the incorrect section.
- mpdehaan2 13y agoSure thing -- basically the 'vars/' directory on a role loads in variables that are always set, basically constants.
- anentropic 13y agoThanks for the write up... I am also considering both of these. I've hated every minute of working with Chef - particularly the Ruby DSL which as you note above is a terrible idea.
- kbd 13y agoCan you explain why templating in Salt is better than using conditionals[1], loops[2], and variables[3] in Ansible playbooks? You can even use templates[4] in Ansible that are Jinja2 as well. [1] http://www.ansibleworks.com/docs/playbooks2.html#conditional-execution http://www.ansibleworks.com/docs/playbooks2.html#conditional... [2] http://www.ansibleworks.com/docs/playbooks2.html#loops http://www.ansibleworks.com/docs/playbooks2.html#loops [3] http://www.ansibleworks.com/docs/playbooks2.html#variable-file-separation http://www.ansibleworks.com/docs/playbooks2.html#variable-fi... [4] http://www.ansibleworks.com/docs/modules.html#template http://www.ansibleworks.com/docs/modules.html#template