3 ms·

My favorite tool this year has been SaltStack. It manages the entire lifecycle of our VMs now (provisioning and state management) and it was very easy to create

by tapoxi 10y ago

My favorite tool this year has been SaltStack. It manages the entire lifecycle of our VMs now (provisioning and state management) and it was very easy to create a Slack bot with it that can update our production/dev environments. Salt is a little confusing at first, since it's essentially just a framework for systems management with Python + ZeroMQ, but you can do a lot with it.

gouggoug 10y ago
I've tried reading the saltstack doc many times, I still am very confused. To the point that I've stuck to ansible, despite truly thinking saltstacks might be better. Is there any not confusing doc about saltstack available?
- tapoxi 10y ago
  They recently rewrote the tutorial, which is available here: https://docs.saltstack.com/en/getstarted/ https://docs.saltstack.com/en/getstarted/ The easiest way to learn Salt is by starting with execution modules (https://docs.saltstack.com/en/latest/ref/modules/all/index.html https://docs.saltstack.com/en/latest/ref/modules/all/index.h...), which are just Python modules that abstract the commands underneath and you can blast to machines, such as salt 'web~' pkg.install httpd to install Apache on all servers named web. You can send shell commands directly using cmd.run - salt 'web~' cmd.run 'yum -y install httpd' (Note: I replaced asterisks with tildes in the above example due to HN formatting.) On top of execution modules are state modules (https://docs.saltstack.com/en/latest/ref/states/all/ https://docs.saltstack.com/en/latest/ref/states/all/). You define a state in YAML and tell a host to execute the state with the state.apply execution module. States consist of an id (a unique string identifier), the state module to use, and arguments, like so: base.packages.stable.install: pkg.installed: - pkgs: - git - zsh - mosh The other major components are runners (https://docs.saltstack.com/en/latest/ref/runners/ https://docs.saltstack.com/en/latest/ref/runners/), which are scripts written against the salt API that perform actions on the salt bus, and engines (https://docs.saltstack.com/en/latest/topics/engines/index.html https://docs.saltstack.com/en/latest/topics/engines/index.ht...), which are child processes spawned by the master that listen for and react to events - like the Slack bot I use. One of the included engines is called reactor, which makes it easy to script events in YAML. There are more moving parts I'm not covering here, but I hope this helps you get started.
_jal 10y ago
I love Salt. Worked with it in a past life, and now use Puppet, because that predated me. The pillar model and the patterns around it are great. Heira is a terrible substitute, despite kind of following a superficially similar structure. I also really liked the idea of reactors, but that came to be right around the time I left that gig, so I didn't get to play much with it other than writing some toys. In general, Salt just feels well architected. Puppet, in comparison, feels like a ramshackle collection of useful things that just don't mesh well. The language design makes me think of Perl without a competent language designer. I will say that Salt has a higher upfront learning curve. I highly recommend giving yourself enough time to throw out your first attempt at designing anything more than a simple system setup.
falcolas 10y ago
I too love salt, but its roots as a remote command execution tool really hinder it in a lot of cases. This is especially true when you try to do something outside the well trod path; such as attempting to verify that commands issued by the salt master were actually initiated by an authorized party. In the long run, I think I prefer Ansible, if only because it limits how much control any one server has over your infrastructure. Ansible breaks down when you have a lot of servers (thousands), but IMO at that point you really should be working at a slightly higher level of abstraction with VM images and automated scaling groups.
deathanatos 10y ago
While Salt did great things to our deployment abilities (we didn't really have much prior to it) … it's not a tool I can recommend. It's design in comparable to PHP or MySQL, and I frankly believe someone should write the equivalent of "A Fractal of Bad Design" or "Do Not Pass This Way Again" for it. 1. Salt simply broadcasts commands out to the nodes connected to it. Because it has no concept of who should be connected to it, it cannot compute whether a node is missing, or if that missing node matters. It's test.ping command is just another command, too, so it suffers the same problems rendering it useless as a ping command 1. Salt's CLI will return success on failure. 1. It is not able to parallelize within a node. It helps to know what a "state" looks like in Salt past here (this is YAML): a_name: # the name of the state; the name/and mapping value here comprise the state pkg.installed: # a state function; this installs a package - arg1: value # args to the function. Yes, it's a list of single-element maps. - arg2: value user.present: # another state function - … These are effectively steps that salt will execute, typically in the order you define them, with some exceptions: a. you can specify dependencies b. you can specify that things run "first" or "last" Also, note that this YAML file is templated with Jinja2. 1. You can't create and depend on a "PHONY" target; this means if you want to depend on the result of several states, you're SoL. You can just inline the set of states that you need, everywhere you need them, which is bad, or you can use a temporary file on disk, which is a hack. 1. Attempting to write code (which, really, is what SLS is) in YAML is crazy. (You can actually write these in at least 4 different languages! All Salt needs is a JSON-like structure.) 1. It is not able to pass information between "states" (a "state" in salt is a task in the grand list of stuff it needs to execute). 1. The error reporting leaves much to be desired. If you make a mistake in a YAML file, you can easily receive back errors with wrong line numbers, wrong file names, quoting the wrong part of the file. 1. At least when we used it, there was no way to properly escape inputs to the YAML file. (This might have been fixed; I honestly can't remember. At some point, it was "fixed", but not really, because the fix didn't work for any practical purpose.) 1. The minions would just "crash", and by crash, I mean, just stop responding. Since its not an outright crash 1. Bug reports were generally met with "you're not using the latest version, please upgrade"; generally, I'm understanding of this attitude, as it takes some work to determine if a bug being experienced in an old version is still present in a new version. Salt's architecture made upgrading nigh-impossible: minions/servers of different versions weren't compatible; DNS couldn't be used to switch minions over in some of our hair-brained ideas to gradually upgrade as the minions would cache DNS results indefinitely. 1. Minions would reconnect automatically; for whatever reason, reconnecting took a considerable toll on the server. If you hit the point where there were too many minions talking to the server, the fleet as a whole would go into a death spiral: too many minions attempting to connect causes an already connected one to miss a keepalive ping, and reconnect. Now you have yet another minion attempting to reconnect, and the problem is worse. More and more minions start doing this, and you're hosed. We had to restart the entire fleet of minions (by hand, b/c our manner of running a distributed command on the fleet was salt) multiple times. 1. Salt in some places, such as templating a file on a minion, needs to reference a file on the server. A relative path would have sufficed wonderfully, but instead Salt uses "salt: URLs". a. they're not URLs, and b. they MUST be absolute. This means that if you move a subtree of stuff (such as for refactoring), you're forced to adjust these URLs. Thankfully, they're easily greppable.

by tapoxi 10y ago

gouggoug 10y ago

I've tried reading the saltstack doc many times, I still am very confused. To the point that I've stuck to ansible, despite truly thinking saltstacks might be better. Is there any not confusing doc about saltstack available?

tapoxi 10y ago
They recently rewrote the tutorial, which is available here: https://docs.saltstack.com/en/getstarted/ https://docs.saltstack.com/en/getstarted/ The easiest way to learn Salt is by starting with execution modules (https://docs.saltstack.com/en/latest/ref/modules/all/index.html https://docs.saltstack.com/en/latest/ref/modules/all/index.h...), which are just Python modules that abstract the commands underneath and you can blast to machines, such as salt 'web~' pkg.install httpd to install Apache on all servers named web. You can send shell commands directly using cmd.run - salt 'web~' cmd.run 'yum -y install httpd' (Note: I replaced asterisks with tildes in the above example due to HN formatting.) On top of execution modules are state modules (https://docs.saltstack.com/en/latest/ref/states/all/ https://docs.saltstack.com/en/latest/ref/states/all/). You define a state in YAML and tell a host to execute the state with the state.apply execution module. States consist of an id (a unique string identifier), the state module to use, and arguments, like so: base.packages.stable.install: pkg.installed: - pkgs: - git - zsh - mosh The other major components are runners (https://docs.saltstack.com/en/latest/ref/runners/ https://docs.saltstack.com/en/latest/ref/runners/), which are scripts written against the salt API that perform actions on the salt bus, and engines (https://docs.saltstack.com/en/latest/topics/engines/index.html https://docs.saltstack.com/en/latest/topics/engines/index.ht...), which are child processes spawned by the master that listen for and react to events - like the Slack bot I use. One of the included engines is called reactor, which makes it easy to script events in YAML. There are more moving parts I'm not covering here, but I hope this helps you get started.

_jal 10y ago

I love Salt. Worked with it in a past life, and now use Puppet, because that predated me. The pillar model and the patterns around it are great. Heira is a terrible substitute, despite kind of following a superficially similar structure. I also really liked the idea of reactors, but that came to be right around the time I left that gig, so I didn't get to play much with it other than writing some toys. In general, Salt just feels well architected. Puppet, in comparison, feels like a ramshackle collection of useful things that just don't mesh well. The language design makes me think of Perl without a competent language designer. I will say that Salt has a higher upfront learning curve. I highly recommend giving yourself enough time to throw out your first attempt at designing anything more than a simple system setup.

falcolas 10y ago

I too love salt, but its roots as a remote command execution tool really hinder it in a lot of cases. This is especially true when you try to do something outside the well trod path; such as attempting to verify that commands issued by the salt master were actually initiated by an authorized party. In the long run, I think I prefer Ansible, if only because it limits how much control any one server has over your infrastructure. Ansible breaks down when you have a lot of servers (thousands), but IMO at that point you really should be working at a slightly higher level of abstraction with VM images and automated scaling groups.

deathanatos 10y ago

While Salt did great things to our deployment abilities (we didn't really have much prior to it) … it's not a tool I can recommend. It's design in comparable to PHP or MySQL, and I frankly believe someone should write the equivalent of "A Fractal of Bad Design" or "Do Not Pass This Way Again" for it. 1. Salt simply broadcasts commands out to the nodes connected to it. Because it has no concept of who should be connected to it, it cannot compute whether a node is missing, or if that missing node matters. It's test.ping command is just another command, too, so it suffers the same problems rendering it useless as a ping command 1. Salt's CLI will return success on failure. 1. It is not able to parallelize within a node. It helps to know what a "state" looks like in Salt past here (this is YAML): a_name: # the name of the state; the name/and mapping value here comprise the state pkg.installed: # a state function; this installs a package - arg1: value # args to the function. Yes, it's a list of single-element maps. - arg2: value user.present: # another state function - … These are effectively steps that salt will execute, typically in the order you define them, with some exceptions: a. you can specify dependencies b. you can specify that things run "first" or "last" Also, note that this YAML file is templated with Jinja2. 1. You can't create and depend on a "PHONY" target; this means if you want to depend on the result of several states, you're SoL. You can just inline the set of states that you need, everywhere you need them, which is bad, or you can use a temporary file on disk, which is a hack. 1. Attempting to write code (which, really, is what SLS is) in YAML is crazy. (You can actually write these in at least 4 different languages! All Salt needs is a JSON-like structure.) 1. It is not able to pass information between "states" (a "state" in salt is a task in the grand list of stuff it needs to execute). 1. The error reporting leaves much to be desired. If you make a mistake in a YAML file, you can easily receive back errors with wrong line numbers, wrong file names, quoting the wrong part of the file. 1. At least when we used it, there was no way to properly escape inputs to the YAML file. (This might have been fixed; I honestly can't remember. At some point, it was "fixed", but not really, because the fix didn't work for any practical purpose.) 1. The minions would just "crash", and by crash, I mean, just stop responding. Since its not an outright crash 1. Bug reports were generally met with "you're not using the latest version, please upgrade"; generally, I'm understanding of this attitude, as it takes some work to determine if a bug being experienced in an old version is still present in a new version. Salt's architecture made upgrading nigh-impossible: minions/servers of different versions weren't compatible; DNS couldn't be used to switch minions over in some of our hair-brained ideas to gradually upgrade as the minions would cache DNS results indefinitely. 1. Minions would reconnect automatically; for whatever reason, reconnecting took a considerable toll on the server. If you hit the point where there were too many minions talking to the server, the fleet as a whole would go into a death spiral: too many minions attempting to connect causes an already connected one to miss a keepalive ping, and reconnect. Now you have yet another minion attempting to reconnect, and the problem is worse. More and more minions start doing this, and you're hosed. We had to restart the entire fleet of minions (by hand, b/c our manner of running a distributed command on the fleet was salt) multiple times. 1. Salt in some places, such as templating a file on a minion, needs to reference a file on the server. A relative path would have sufficed wonderfully, but instead Salt uses "salt: URLs". a. they're not URLs, and b. they MUST be absolute. This means that if you move a subtree of stuff (such as for refactoring), you're forced to adjust these URLs. Thankfully, they're easily greppable.