That was my comment, based on limited use of Salt. I've now been using Salt in production for about three months (new job) and I would make the same comment.
Salt states can, theoretically, do everything Puppet can do. In practice I find that the ecosystem around Salt states is very thin. I find it difficult to locate states that other people have developed and those are usually not general enough for me to use without modification. I haven't found many good examples of Salt states or documentation about how to write testable and generic states for Salt; something Puppet has a strong ecosystem around. Some things that Puppet does easily like parameterized classes, hiera, and collected resources are things that seem to be missing or difficult to implement in Salt. I like Salt and I like the /idea/ of Salt as an OSS configuration management platform. I think Salt will always lag behind Puppet in some ways. In other ways Salt is way ahead of Puppet, especially with cloud provisioning and making changes based on the current/changing states of other systems. I would use Salt to bootstrap a system and Puppet/CfEngine to maintain state on that system. The right tool for the right job. On Mon, Mar 30, 2015 at 9:27 PM, Leon Towns-von Stauber <leo...@occam.com> wrote: > Resurrecting this thread because I have a question. We use CFEngine 2 at my > current shop, and are now evaluating CFEngine 3 and Salt as replacements. I > was hoping to get clarification on this comment: > >> I would use Salt when I need to build full application stacks >> including many dependent types of systems, and don't need to manage >> the state of the systems. > > This isn't the only place I've heard Salt described as more of an imperative > system (i.e. "Do this"), as opposed to a system that describes a desired > state (i.e. "Make it like this"), which CFEngine does so well. > > However, having started to look at Salt, I don't really get the criticism (if > you take it as one). Based on limited exposure so far, it seems just as > capable as CFEngine or Puppet of specifying a desired configuration and > executing on it; it doesn't seem all that different in overall philosophy. > For anyone familiar with the issue, what am I missing? Or, perhaps, is that > description of Salt based on earlier versions, the shortcomings of which have > been addressed in current releases? > > - Leon > >> From: Atom Powers <atom.pow...@gmail.com> >> Date: November 13, 2014 at 12:45:26 PM PST >> To: "Edward Ned Harvey (lopser)" <lop...@nedharvey.com> >> Cc: LOPSA Technical Discussions <t...@lopsa.org> >> Subject: Re: [lopsa-tech] Puppet, Chef, Etc >> >> On Wed, Nov 12, 2014 at 4:42 PM, Edward Ned Harvey (lopser) >> <lop...@nedharvey.com> wrote: >>> I'd like to build a VM on my local vmware or virtualbox or whatever, and >>> then essentially clone it to AWS or vice versa... Make some change on a >>> development machine, test it, and then after it's validated, replicate that >>> change to the production environment by sending essentia >>> lly the snapshot differential of the configuration. >>> >>> For some reason, this is what I thought puppet/chef/etc did. Am I wrong? >>> Is this a pipe dream? >> >> >> This sounds more like Docker than Configuration Management. >> >> I've used CfEngine 2 for many years and Puppet for several. I know >> people who use Chef, Ansible, and Salt. Here are my impressions: >> >> TL;DR: it depends >> I would use Puppet when I have a wide variety of configurations and >> systems tend to stay in use for months or years. >> I would use Chef when I build a lot of similar systems and keep them >> up for days or weeks. >> I would use Ansible when I need to push changes to a system "right >> now" but don't need to manage the state of that system. >> I would use Salt when I need to build full application stacks >> including many dependent types of systems, and don't need to manage >> the state of the systems. >> >> Puppet is good for maintaining the state of your systems. >> It is, more than any other tool, it is a description of how the system >> should be configured. >> It is difficult to scale up to large scale (thousands of systems), >> mostly because all the work of building the catalog is centralized on >> the PuppetMaster. >> Because the PuppetMaster knows everything about all your systems it is >> trivial to do things like "create a Nagios check for all systems with >> Apache installed." >> Only the puppet master knows the secrets of all the systems, each >> system doesn't know anything about other systems; that makes it >> difficult to do something like "build the application server as soon >> as the databases server is built"; aka "orchestration" >> Puppet implements a DSL, so it is "easy" to rebuild it in other >> languages if the need presents itself. >> >> Chef is good for deploying systems. >> Chef is essentially an extension of Ruby, using Ruby syntax and >> libraries to create "executable documentation" about the system. You >> will *always* need Ruby on every Chef-managed system. >> Chef scales because all the work is done on the client, so the work is >> distributed. >> It can be easy to "accidentally" bleed secrets between systems >> because, typically (although I believe there has been work to correct >> this) each system gets the full set of instructions for every system. >> >> Ansible is, literally, "ssh in a for loop"; sometimes that is what you >> want. Ansible is great at deploying systems and at making instant >> changes to a group of systems. >> Ansible sends commands to each managed system or group or systems, >> runs the commands, and returns the output of the commands. >> You run Ansible manually, I haven't talked to anybody who runs Ansible >> on an automatic schedule like Puppet and Chef are typically used. >> I know people who use Puppet and Ansible together. >> >> I understand Salt uses a message queue to deliver configuration to >> systems, similar to how Ansible uses SSH. >> Salt is able to orchestrate configurations. It knows as soon as the >> database server is built and can start building the application >> server. >> >> I have a lot of love for CfEngine3, although I've never used it and >> don't know anybody who is. >> >> >> >> -- >> Perfection is just a word I use occasionally with mustard. >> --Atom Powers-- >> _______________________________________________ >> Tech mailing list >> Tech@lists.lopsa.org >> https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech >> This list provided by the League of Professional System Administrators >> http://lopsa.org/ > _______________________________________________ > Tech mailing list > Tech@lists.lopsa.org > https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech > This list provided by the League of Professional System Administrators > http://lopsa.org/ -- Perfection is just a word I use occasionally with mustard. --Atom Powers-- _______________________________________________ Tech mailing list Tech@lists.lopsa.org https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech This list provided by the League of Professional System Administrators http://lopsa.org/
