+1 for Chef on my side. I’ve got it managing over 500 Windows servers (and a few Linux ones) on an Azure instance that’s just 8GB and the server barely sweats. It can also do neat things like act as an encrypted password management store for your scripts. For Windows I wouldn’t dig too deep into the DSC side of things. Chef can do anything DSC does, and DSC is still a little buggy. I’d created an entire DSC deployment for my clusters, and then had to scrap it looking for another solution due to some core issues.
I’ve played with Salt a couple years ago on a Linux infrastructure, but I found the agents a little buggy and ended up switching to Chef and sticking with it. The hot CMS these days seems to be Ansible, but I haven’t had reason to play with it, and my current employer recently partnered with Chef officially so I’ve had little reason to switch. Best, -kz On 3/31/15, 9:21 PM, "Leon Towns-von Stauber" <leo...@occam.com> wrote: >One of the main reasons we're looking at Salt as an alternative to CFE 3 is >the support for Windows, which is pretty expensive for CFE. Our Windows team >would like something better than SMS, and it'd be nice if we could share the >same tool for Windows and Linux. > >Thanks to everyone for the responses. I've found that there are very few >people with exposure to more than one configuration management system >(actually, there are shockingly few people that have experience with *any* >CMS); it helps to have the members of LOPSA to draw on for questions like this. > >- Leon > >On Mar 30, 2015, at 11:42 PM, Dennis wrote: > >> On Mon, Mar 30, 2015 at 9:41 PM, Brandon Allbery <allber...@gmail.com> wrote: >>> On Tue, Mar 31, 2015 at 12:27 AM, Leon Towns-von Stauber <leo...@occam.com> >>> wrote: >>>> >>>>> 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? >>> >>> >>> Pretty much, yes; it's had the capability for a year or so, but it's still >>> "newish". (Earlier versions supported one "state", which de facto ended up >>> being "do these things" as opposed to "make the system look like this", as I >>> understand it. Some of the tutorials and documentation still assume that's >>> how you use it.) >> >> Realistically you can use both, or neither. >> >> I can't comment on what was wrong with the state system back then for >> that to come up though. >> >> I do want to point out that Salt State files are very easy on the eyes >> compared to CFE promises. >> >> http://docs.saltstack.com/en/latest/topics/tutorials/starting_states.html >> >> Also you can template them, one Pythonic example being: >> http://docs.saltstack.com/en/latest/ref/renderers/all/salt.renderers.pyobjects.html >> >> If everyone has more experience with CFE on the team then why switch? >_______________________________________________ >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/
