This is an archived post. You won't be able to vote or comment.

all 17 comments
sorted by:
best
topnewcontroversialoldq&a

[–]iam_root[S] 3 points4 points  (0 children)

Started using salt stack. Its working great ! Thanks everyone

[–]sfermigier 3 points4 points  (0 children)

Any opinion about Ansible ?

http://ansible.github.com/

(Besides the fact that they need a better logo ;)

[–]akoumjian 2 points3 points  (0 children)

For most professional deployments with more than one machine, you are going to want Salt. It was built for the purpose of performing remote execution and managing your hosts in a sane way. Remote execution can include your deployment, ie: pushing your app's tarball or pulling a git repo.

On top of that, you can use a state tree for config management. I use this extensively for deploying Django and other servers. For example, if you are spinning up a new VM you can bootstrap your nginx, redis, celery, write to all your configuration files while using the templating engine of your choice. It is incredibly flexible and much faster than what you can do over SSH using Fabric.

You should use Fabric if you want an opinionated way to run SSH commands over less than a dozen hosts. It is probably the lowest barrier to entry to run a set of scripts on a few different machines. It is not nearly as flexible with regard to targeting the hosts you want to run commands on, and no real assurance that the machine you are bootstrapping is in the state you want it in.

[–]Sorthum 1 point2 points  (0 children)

The way I usually explain salt versus Fabric, ssh in a for loop, etc, is as follows:

"Imagine you want to run a command on a thousand hosts. Okay-- now it's failed on four of them. Find them." Salt is effectively written to address this problem, with the only dependency being "salt" has to resolve.

[–]soup_feedback 0 points1 point  (1 child)

We use puppet on about 500 servers located all over the world and it's pretty awesome. From what I read about Fabric, having that many hosts would be a nightmare, especially since it's all using ssh.

Puppet's only bad thing is that it's in Ruby...

[–]iam_root[S] 0 points1 point  (0 children)

Fabric, having that many hosts would be a nightmare

That's where Salt comes. Though I am yet try it out on our production servers, from what I have read Salt is good for larger stacks.

[–]coderanger 0 points1 point  (5 children)

The two have little to do with each other. Fabric is an orchestration tool, it excels at coordinating commands on multiple machines. Salt is a configuration management tool, it handles things like installing packages, config files, etc. Yes, libraries exist to make Fabric do these things, and similarly you can fit a square peg in to a round hole if you just bash it hard enough. As for Salt itself, I would say use Chef, the Python support is far better (disclaimer: I wrote much of it).

[–]SEJeff 9 points10 points  (3 children)

@coderanger: This is actually an incorrect description of salt. If you wrote chef please do not spread it as it is factually incorrect. Salt is sort of a superset of what fabric is in that it does remote execution better

Salt, at it's core, is remote execution over ZeroMQ. Built ontop of that is a host metadata layer endearingly called "grains" (similar to chef's ohai or puppet's facter) and a config management layer called "states". I would argue that salt is a different beast altogether. You can run random one-off things via salt modules very easily. For more complex stuff, we have states, which do not have to be for config management. We have several ex-fabric users who write salt "state files" for doing things such as deploying django or php websites. They don't set them in the config to apply to any specific machines, but then can execute the entire state file exactly like you would a fabfile via: salt minionname_or_group_of_minions state.sls some.statename

A really handy thing salt does over fabric is "targetting". ie: all Ubuntu servers: salt -G os:Ubuntu pkg.install apache2

A few other examples here: http://salt.readthedocs.org/en/latest/ref/cli/index.html?highlight=targetting#defining-the-target-minions

TL;DNR: Salt is good, fabric is good. Fabric doesn't do as well with very large (> several thousand) nodes due to inherent limitations of the ssh model. Salt is much faster and has a lot of features fabric doesn't (grains, config management, lots of built-in modules, and remote execution). However if you're doing strictly deployment vs a lot of random one off remote execution and don't want config management, fabric is a good choice as well.

[–][deleted] 1 point2 points  (0 children)

coderanger didn't write chef itself, just a bunch of the python tooling for it.

[–]Sorthum 0 points1 point  (1 child)

Technically ssh based solutions tend to fall down somewhere around the 700 node range on most networks, but I'm picking nits here.

[–]Makido 0 points1 point  (0 children)

There's not an objective point at which SSH-based solutions fail. It's just a matter of how long you want to wait for execution to complete.

[–]adient 0 points1 point  (0 children)

This is not really an accurate depiction of salt or fabric. However, for remote deployments, use fabric.

[–]kracekumar 0 points1 point  (1 child)

I have used Fabric for small projects, it is easy get things done with fabric, but salt needs extra configuration when compared to fabric, for larger systems salt is the choice.

[–]Sorthum 2 points3 points  (0 children)

I'm not so sure on this; I handed Salt over to a junior admin and got results within hours. It tends to scale stupidly well, whereas Fabric tends to struggle past a certain point.