4 ms·
I don't really consider salt as an alternative to puppet/chef. Although it can do many of the same things as both of them, there are a few important difference
by 23david 14y ago
I don't really consider salt as an alternative to puppet/chef.
Although it can do many of the same things as both of them, there are a few important differences. 1) By default, it encourages the use of YAML definitions which makes the codebase more readable/manageable over time. 2) It incorporates a first-class remote execution environment that replaces the need for parallel ssh or ssh almost entirely. 3) It leverages zmq as a data bus, and can easily transfer files or live data over the bus in multiple different topologies. 4) It uses python instead of ruby, which to many sysadmins & devops engineers used to bash scripting is generally more readable than ruby code.
Ansible shares a lot of similar characteristics, and it's great seeing both projects taking off. Definitely room for more than one system in this area, and everyone benefits from the healthy competition. It's not terribly complicated to have different systems manage different parts of your stack anyhow. You can easily use chef/salt/ansible all at once and use each project to manage different layers of your stack.
Just don't use capistrano... :-)
- lobster_johnson 14y ago> It uses python instead of ruby, which to many sysadmins & devops engineers used to bash scripting is generally more readable than ruby code. I disagree. If anything, Ruby is closer to Bash (in a good way, mind you) whereas Python's various syntax choices (white-space sensitivity, parens for function calls, some things only available as imported modules, etc.) makes it more different. Consider bash: if [ `which foo` == "/usr/bin/foo" ]; then do_stuff fi compared to Ruby: if `which foo`.strip == "/usr/bin/foo" do_stuff end compared to Python: import os if os.popen("which foo").read().strip() == "/usr/bin/foo": do_stuff() Also, I would be careful about making generalizations without the data to back it up. "Many sysadmins & devops prefer..." is what Wikipedia editors would call weasel words. I have only anecdotal evidence myself; I personally used to be a Python guy but now prefer Ruby; and some time ago my company hired a sysadmin/devops guy who came from Python, but grew to prefer Ruby once he started to learn it while working for us. Considering that both Puppet and Chef are written in (almost entirely) Ruby, I would say that the sysadmin/devops field is currently leaning more strongly toward Ruby than Python. Although I'm sure bash dominates both. Don't get me wrong, in terms of productivity and so forth, Python and Ruby are entirely on an equal footing.
- IamBren 14y agoI generally agree with your response. My only slight irritation is with how you wrote out the Python code. It looks a bit...uglier? and more verbose than it needs to be, especially compared to the others. This looks better to me: from commands import getoutput if getoutput('which bash') == '/bin/bash': do_stuff() Although if your goal is to determine if e.g. bash is located in /bin, then I would do: bash: if [ -e '/bin/bash' ]; then do_stuff fi (I don't know Ruby.) Python: import os.path if os.path.exists('/bin/bash'): do_stuff() I know I'm just splitting hairs. :)
- lobster_johnson 14y agoThe point was definitely not the logic of the examples! Rather to show three core similarities/differences: * Ruby has bashisms like `foo`; Python requires a function call. * Ruby has a nesting syntax similar to bash with if/end; Python is whitespace-sensitive. * Ruby has method calls without parentheses, similar to bash commands, whereas Python requires them. > Although if your goal is to determine if e.g. bash is located in /bin, Actually, that was not the goal at all. The goal (which, again, is irrelevant to my point) was to determine if the PATH-resolved executable binary "foo" was in a specific location. Rest assured that I would not use "which" in a real-life app. :-) (Thanks for commands.getoutput(), my Python is rusty.)
- merlincorey 14y agoNot really the kind of comment HN generally approves, but I felt compelled to share... > Just don't use capistrano... :-) At one of my previous start-ups, we used to call it, "crapistrano". That is all!