6 ms·

Salt stack, the simpler puppet

35 points by gcmalloc 13y ago

rdtsc 13y ago
I started looking at ansible but like salt stack better now. Windows support is one think I liked better about it. I wish I didn't have to deal with Windows but unfortunately I do and salt has the support for it. http://docs.saltstack.com/ref/windows-package-manager.html http://docs.saltstack.com/ref/windows-package-manager.html
- cutie 13y ago
  I have some windows admin work to do as well. However I prefer that ansible doesn't require daemons on every host, so I was a bit torn on which to use. Searched around a bit and found pave. It has the things I need (admittedly straightforward) and is about as simple as it gets. Would be great if it could get some love, as I appreciate the no-nonsense design. https://bitbucket.org/mixmastamyk/pave https://bitbucket.org/mixmastamyk/pave
  - rdtsc 13y ago
    salt has a daemon-less mode as well: http://docs.saltstack.com/topics/ssh/ http://docs.saltstack.com/topics/ssh/
aethr 13y ago
Their website doesn't make it obvious where to go if you just want to download salt and get started. It seems to want to steer you towards SaltStack Enterprise. However, you can find installation instructions (which include where to download) for all OSes here: http://docs.saltstack.com/topics/installation/index.html http://docs.saltstack.com/topics/installation/index.html I have yet to check Salt out, but as someone who's just come off the back of Puppet's steep learning curve and lack of robust modules, it's something I'd like to look into.
- bsaul 13y ago
  Here : http://docs.saltstack.com/topics/tutorials/walkthrough.html http://docs.saltstack.com/topics/tutorials/walkthrough.html And if you're on a mac : http://docs.saltstack.com/topics/tutorials/walkthrough_macosx.html http://docs.saltstack.com/topics/tutorials/walkthrough_macos...
secstate 13y ago
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/
dataops_log 13y ago
Big fan of the speed and simplicity of salt vs puppet. Plus it is multiple useful tools in one for me (configuration management, system provisioning and remote execution)
- stp-ip 13y ago
  In my opinion it still lacks more automatic deploy mechanisms. Ansible has some great ideas, but I guess the time to write your deploy scripts is needed. I'm still hoping for a salt package like system. (https://github.com/saltstack-formulas https://github.com/saltstack-formulas) Where you only use your top.sls and perhaps some custom pillar data, to define how packages interact or where packages are needed. Define wordpress running on 2 appservers + 1 database node + 1 loadbalancer with ssl termination and export db and pipe it through gpg via this pillar key. etc. pp
njpatel 13y ago
At Ayatii we use Salt both for initial configuration and scaling. It's very easy to get setup, and the concepts of States, Pillars and Reactors are easy enough to grasp and start hacking useful utilities for your deployment. For instance, with a couple lines of Python, I was able to 'react' to any new DigitalOcean instance that was created and able to update DNS records or Nginx config (if it was a certain type of instance). As someone is more of a developer than a infrastructure person, Salt saved me a lot of time.
- stp-ip 13y ago
  njpatel I would love to get my hands on your python code on the reactor stuff. Still haven't found a real world example for updating loadbalancers or dns.
  - njpatel 13y ago
    I was going to do a blog post but never got around to it! I copy-and-pasted the DNS one we use into a gist (removing specific bits of our setup). We use DO, but this should get you to a point where all the bits are working and then you can do as you wish. Excuse the Python code...I'm very much not a Python guy! https://gist.github.com/njpatel/8603816 https://gist.github.com/njpatel/8603816
    - stp-ip 13y ago
      Thanks
blueskin_ 13y ago
I really want to give Salt a try. I've worked with Puppet and find the syntax ugly and the logic weird (e.g. all variables are essentially final and can't be changed in cases after having a value).
- dijit 13y ago
  You'd like chef then, nothing is immutable, everything can be changed on a case by case basis using #override
  - viraptor 13y ago
    But it also results in a mess of what-can-override-what. You can't have just #override. You've got "automatic", "default", "override" and later added "force_override" and "force_default", because "override"/"default" were not enough. And I'm still running into situations (especially when working with different teams deploying on the same host) where I want to override something that can't be changed anymore (or doesn't merge the way I need to). This is one of the most annoying parts of chef for me. And it is quite complex: http://docs.opscode.com/essentials_cookbook_attribute_files.html http://docs.opscode.com/essentials_cookbook_attribute_files....
    - blueskin_ 13y ago
      That sounds almost exactly like the current problem I'm grappling with in Puppet. Variables can be overridden and inherited, except when they can't.
nathan_f77 13y ago
We use saltstack at Zenpayroll.com to manage our servers, and I think it works pretty well. Not 100% sold on the jinja/python stuff, but it does the job.
kingrolo 13y ago
Am loving Salt since switching from Puppet a year or so ago. In conjunction with Salt Cloud I type a one liner to spin up a new Linode, battle harden it, and install my stack on it. They've also recently added some states for supporting docker containers which looks interesting.
VSpike 13y ago
I started looking at Salt and really liked what I saw, but the first task I had to do was to provision some Windows Servers on Rackspace or AWS and configure them. Like the other commenter, I wish I didn't have to deal with Windows but I'm stuck with it. I found Saltcloud a bit bleeding edge for a newcomer to configuration management (although improving all the time) with Windows being its biggest weakness. When it comes to configuration, it also seemed to me (admittedly with limited experience) the Windows support in Salt is a poor cousin rather than an equal citizen. Don't get me wrong, it's good they have it at all, but you'll need to do a lot more work yourself. I plan to look at Chef next as a possible alternative since the Windows support seems more mature. No comments on Chef yet so I'd be interested to hear anyone else's experience with it, especially for a newcomer to config management tools.
- anentropic 13y ago
  I rather hated the Ruby DSL in Chef... turned me off the idea of DSLs in general in fact. I haven't used Saltstack but the use of (jinja-)templated YAML or just plain Python for state files seems like a big plus.
joaomsa 13y ago
My main experience is with Puppet, though I have migrated legacy systems from CFEngine as well. My main gripes with Puppet are that, at times, the DSL is restrictive and you have to either rely on ugly Execs or dropdown into Ruby extensions. I can see how this can be off putting to beginners. The advantages though once we've gotten comfortable have made our infrastructure smarter and more resilient. - Idempotency (If you're careful) - Abstracting configuration data vs methods. Passwords/Keys/Addresses are kept in a Hiera config file and the manifests merely access these variables instead of hardcoding when applying changes. - PuppetDB as a canonical reference of the state of all our infrastructure. What are all my servers running MySQL? Which version? Where are all my Ceph MDSs? - Exported resources (also relying on PuppetDB), enabling propagation of information about new nodes to all others. A godsend when paired with Nagios. Does Salt have anything that matches these use cases?
- sergiosgc 13y ago
  We switched away from puppet towards Salt. The broad stroked opinion is that salt covers all of puppet 's use cases, with advantages in terms of both performance and extensibility. It is idempotent; there is a central configuration db (a couple of options, actually; we use pillar, a YAML set of files for its simplicity). Exported resources are handled a bit differently (you pull data from servers at config time instead of pushing at export time) but cover the same functionality. The same functionality covers software configuration inventory. Where it excels is in performance. Our deployment runs on puppet took some 15min, salt handles them in 30s. I also like its codebase. It is clear and well documented, easy to extend. I am biased towards python instead of Ruby, so take my opinion with a grain of salt (heh:-)
- viraptor 13y ago
  - Idempotency Yes, the run will report on each salt state which can result in either: failed (with a reason), succeeded (with a description what changed), succeeded (nothing changed). Each salt state provided by the project is also intelligent about its use of resources - for example, if you have multiple pkg.installed, the list of available packages will be pulled only once and all states will be able to determine quickly if they need to run. - Abstracting configuration data vs methods Methods -> salt states; Configuration data -> grains/pillar. Grains are kind of attributes that belong to a host (like hostname, system version, installed packages, available ips, etc.), while pillar is a plugin system that can provide external data (it can be used like puppetdb too; I've got a plugin that pulls json files from s3 and talks makes it available as a simple hash for example). If you know chef, think attributes/databags (but better). - PuppetDB as a canonical reference of the state of all our infrastructure. It doesn't actually provide this out of the box, but provides the needed elements so this is trivial. Basically you can query all your nodes from the salt server (or nodes can query each other). You just need to extract the bits you need and save them to whatever destination you want. For example on the server run `salt -G 'roles:database' grains.item mem_total` and save the data. You can also define a "returner" which is a plugin that handles the data you get back and for example implement something that writes the data back into your information store/cmdb. - Exported resources (also relying on PuppetDB), enabling propagation of information about new nodes to all others. Pillar again. Although depending on what you want to achieve, you may want to enable some querying between the nodes, so that one of them can just broadcast some message at runtime and work on results.

35 points by gcmalloc 13y ago

rdtsc 13y ago

I started looking at ansible but like salt stack better now. Windows support is one think I liked better about it. I wish I didn't have to deal with Windows but unfortunately I do and salt has the support for it. http://docs.saltstack.com/ref/windows-package-manager.html http://docs.saltstack.com/ref/windows-package-manager.html

cutie 13y ago
I have some windows admin work to do as well. However I prefer that ansible doesn't require daemons on every host, so I was a bit torn on which to use. Searched around a bit and found pave. It has the things I need (admittedly straightforward) and is about as simple as it gets. Would be great if it could get some love, as I appreciate the no-nonsense design. https://bitbucket.org/mixmastamyk/pave https://bitbucket.org/mixmastamyk/pave
- rdtsc 13y ago
  salt has a daemon-less mode as well: http://docs.saltstack.com/topics/ssh/ http://docs.saltstack.com/topics/ssh/

aethr 13y ago

Their website doesn't make it obvious where to go if you just want to download salt and get started. It seems to want to steer you towards SaltStack Enterprise. However, you can find installation instructions (which include where to download) for all OSes here: http://docs.saltstack.com/topics/installation/index.html http://docs.saltstack.com/topics/installation/index.html I have yet to check Salt out, but as someone who's just come off the back of Puppet's steep learning curve and lack of robust modules, it's something I'd like to look into.

bsaul 13y ago
Here : http://docs.saltstack.com/topics/tutorials/walkthrough.html http://docs.saltstack.com/topics/tutorials/walkthrough.html And if you're on a mac : http://docs.saltstack.com/topics/tutorials/walkthrough_macosx.html http://docs.saltstack.com/topics/tutorials/walkthrough_macos...

secstate 13y ago

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/

dataops_log 13y ago

Big fan of the speed and simplicity of salt vs puppet. Plus it is multiple useful tools in one for me (configuration management, system provisioning and remote execution)

stp-ip 13y ago
In my opinion it still lacks more automatic deploy mechanisms. Ansible has some great ideas, but I guess the time to write your deploy scripts is needed. I'm still hoping for a salt package like system. (https://github.com/saltstack-formulas https://github.com/saltstack-formulas) Where you only use your top.sls and perhaps some custom pillar data, to define how packages interact or where packages are needed. Define wordpress running on 2 appservers + 1 database node + 1 loadbalancer with ssl termination and export db and pipe it through gpg via this pillar key. etc. pp

njpatel 13y ago

At Ayatii we use Salt both for initial configuration and scaling. It's very easy to get setup, and the concepts of States, Pillars and Reactors are easy enough to grasp and start hacking useful utilities for your deployment. For instance, with a couple lines of Python, I was able to 'react' to any new DigitalOcean instance that was created and able to update DNS records or Nginx config (if it was a certain type of instance). As someone is more of a developer than a infrastructure person, Salt saved me a lot of time.

stp-ip 13y ago
njpatel I would love to get my hands on your python code on the reactor stuff. Still haven't found a real world example for updating loadbalancers or dns.
- njpatel 13y ago
  I was going to do a blog post but never got around to it! I copy-and-pasted the DNS one we use into a gist (removing specific bits of our setup). We use DO, but this should get you to a point where all the bits are working and then you can do as you wish. Excuse the Python code...I'm very much not a Python guy! https://gist.github.com/njpatel/8603816 https://gist.github.com/njpatel/8603816
  - stp-ip 13y ago
    Thanks

blueskin_ 13y ago

I really want to give Salt a try. I've worked with Puppet and find the syntax ugly and the logic weird (e.g. all variables are essentially final and can't be changed in cases after having a value).

dijit 13y ago
You'd like chef then, nothing is immutable, everything can be changed on a case by case basis using #override
- viraptor 13y ago
  But it also results in a mess of what-can-override-what. You can't have just #override. You've got "automatic", "default", "override" and later added "force_override" and "force_default", because "override"/"default" were not enough. And I'm still running into situations (especially when working with different teams deploying on the same host) where I want to override something that can't be changed anymore (or doesn't merge the way I need to). This is one of the most annoying parts of chef for me. And it is quite complex: http://docs.opscode.com/essentials_cookbook_attribute_files.html http://docs.opscode.com/essentials_cookbook_attribute_files....
  - blueskin_ 13y ago
    That sounds almost exactly like the current problem I'm grappling with in Puppet. Variables can be overridden and inherited, except when they can't.

nathan_f77 13y ago

We use saltstack at Zenpayroll.com to manage our servers, and I think it works pretty well. Not 100% sold on the jinja/python stuff, but it does the job.

kingrolo 13y ago

Am loving Salt since switching from Puppet a year or so ago. In conjunction with Salt Cloud I type a one liner to spin up a new Linode, battle harden it, and install my stack on it. They've also recently added some states for supporting docker containers which looks interesting.

VSpike 13y ago

I started looking at Salt and really liked what I saw, but the first task I had to do was to provision some Windows Servers on Rackspace or AWS and configure them. Like the other commenter, I wish I didn't have to deal with Windows but I'm stuck with it. I found Saltcloud a bit bleeding edge for a newcomer to configuration management (although improving all the time) with Windows being its biggest weakness. When it comes to configuration, it also seemed to me (admittedly with limited experience) the Windows support in Salt is a poor cousin rather than an equal citizen. Don't get me wrong, it's good they have it at all, but you'll need to do a lot more work yourself. I plan to look at Chef next as a possible alternative since the Windows support seems more mature. No comments on Chef yet so I'd be interested to hear anyone else's experience with it, especially for a newcomer to config management tools.

anentropic 13y ago
I rather hated the Ruby DSL in Chef... turned me off the idea of DSLs in general in fact. I haven't used Saltstack but the use of (jinja-)templated YAML or just plain Python for state files seems like a big plus.

joaomsa 13y ago

My main experience is with Puppet, though I have migrated legacy systems from CFEngine as well. My main gripes with Puppet are that, at times, the DSL is restrictive and you have to either rely on ugly Execs or dropdown into Ruby extensions. I can see how this can be off putting to beginners. The advantages though once we've gotten comfortable have made our infrastructure smarter and more resilient. - Idempotency (If you're careful) - Abstracting configuration data vs methods. Passwords/Keys/Addresses are kept in a Hiera config file and the manifests merely access these variables instead of hardcoding when applying changes. - PuppetDB as a canonical reference of the state of all our infrastructure. What are all my servers running MySQL? Which version? Where are all my Ceph MDSs? - Exported resources (also relying on PuppetDB), enabling propagation of information about new nodes to all others. A godsend when paired with Nagios. Does Salt have anything that matches these use cases?

sergiosgc 13y ago
We switched away from puppet towards Salt. The broad stroked opinion is that salt covers all of puppet 's use cases, with advantages in terms of both performance and extensibility. It is idempotent; there is a central configuration db (a couple of options, actually; we use pillar, a YAML set of files for its simplicity). Exported resources are handled a bit differently (you pull data from servers at config time instead of pushing at export time) but cover the same functionality. The same functionality covers software configuration inventory. Where it excels is in performance. Our deployment runs on puppet took some 15min, salt handles them in 30s. I also like its codebase. It is clear and well documented, easy to extend. I am biased towards python instead of Ruby, so take my opinion with a grain of salt (heh:-)
viraptor 13y ago
- Idempotency Yes, the run will report on each salt state which can result in either: failed (with a reason), succeeded (with a description what changed), succeeded (nothing changed). Each salt state provided by the project is also intelligent about its use of resources - for example, if you have multiple pkg.installed, the list of available packages will be pulled only once and all states will be able to determine quickly if they need to run. - Abstracting configuration data vs methods Methods -> salt states; Configuration data -> grains/pillar. Grains are kind of attributes that belong to a host (like hostname, system version, installed packages, available ips, etc.), while pillar is a plugin system that can provide external data (it can be used like puppetdb too; I've got a plugin that pulls json files from s3 and talks makes it available as a simple hash for example). If you know chef, think attributes/databags (but better). - PuppetDB as a canonical reference of the state of all our infrastructure. It doesn't actually provide this out of the box, but provides the needed elements so this is trivial. Basically you can query all your nodes from the salt server (or nodes can query each other). You just need to extract the bits you need and save them to whatever destination you want. For example on the server run `salt -G 'roles:database' grains.item mem_total` and save the data. You can also define a "returner" which is a plugin that handles the data you get back and for example implement something that writes the data back into your information store/cmdb. - Exported resources (also relying on PuppetDB), enabling propagation of information about new nodes to all others. Pillar again. Although depending on what you want to achieve, you may want to enable some querying between the nodes, so that one of them can just broadcast some message at runtime and work on results.