Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Moving away from Puppet: SaltStack or Ansible?

ryandlane.com

Post reply on HN
Print view View original

51–60 of 182 posts

Re: Moving away from Puppet: SaltStack or Ansible?

#51

Post by fred_durst »

ryan_lane wrote: post #35
fred_durst wrote: post #11

> I did get a “pull request welcome” response on a legitimate bug, which is an anti-pattern in the open source world. Can someone explain why this is an anti-pattern? Is there some sarcasm I'm missing? Seems like exactly the kind of response I appreciate when I submit issues in open source projects.

In this specific case I submitted a bug and was told the bug wasn't valid and it was closed. After I pointed out why this was in fact a valid bug, the bug wasn't reopened, but instead left closed while I was told "you're welcome to submit a PR". Basically I'm being told the bug isn't important enough for the upstream to fix and that they care so little about the bug that they won't even leave it open for someone othe…

> In this specific case I submitted a bug and was told the bug wasn't valid and it was closed.

Maybe that is what you might have said in your blog post instead of a snarky comment. Remember, many people in open source are not from the upper middle class United States / West Coast and will likely not pick up on clever passive aggressive jabs. I completely understand that they are great for being able to deny any accountability for your attacks, but it generally leads to a lot of misunderstanding. Especially from those who do not speak English as their first language.

I really don't mean this to jump on you, but hopefully you might take it as some advice when dealing with large distributed projects that passive aggressive snark, I would guess, ends up actually going over the head of 50% or more of the people.

Re: Moving away from Puppet: SaltStack or Ansible?

#53

Post by GregorStocks »

tootie wrote: post #52

I feel like the entire configruation management movement has passed me by. I still don't understand what value there is in chef/puppet/salt/ansible/docker vs bash or even Perl for that matter. Someone care to set me straight?

When you're managing more than a handful of servers, you very quickly start wanting to be able to run the same command on multiple machines - "upgrade all my API boxes to the not-vulnerable nginx", for instance, or "push this binary out to all my database servers". These sorts of services make that straightforward, and generally provide a large library of prewritten modules to do moderately-complicated things without having to write a lot of boilerplate or read somebody else's Bash scripts or Perl.

Re: Moving away from Puppet: SaltStack or Ansible?

#54

Post by tootie »

GregorStocks wrote: post #53
tootie wrote: post #52

I feel like the entire configruation management movement has passed me by. I still don't understand what value there is in chef/puppet/salt/ansible/docker vs bash or even Perl for that matter. Someone care to set me straight?

When you're managing more than a handful of servers, you very quickly start wanting to be able to run the same command on multiple machines - "upgrade all my API boxes to the not-vulnerable nginx", for instance, or "push this binary out to all my database servers". These sorts of services make that straightforward, and generally provide a large library of prewritten modules to do moderately-complicated things without…

Well, I've done that just using remote shell commands. And I'd have an easier time reading someone else's bash than I would their ansible whatevers. Is it actually more concise?

Re: Moving away from Puppet: SaltStack or Ansible?

#55

Post by gnoway »

dgallagher wrote: post #12

Does anyone have experience using Configuration Management software in a heterogeneous environment? For example, I've seen large environments running Windows 2008/2008R2/2012/2012R2, various flavors and versions of Linux including Ubuntu Server, CentOS, SUSE, etc... What's the pretty? What's the ugly? I understand consolidation and standardization of operating systems is usually the best state to be in, but in a lot…

This is the sort of question that needs a blog post to answer, IMO.

I have not had enough time with any of these tools to speak to the pretty, but I can speak to the ugly. The chief issues with these tools on Windows are package management, overall speed, and community focus on not-Windows.

Package management is the worst, IMO, and it stems from Windows and the majority of it's 'software universe' being commercial. Software is expected to install on many editions of Windows; it is not common to see edition-specific packages for anything not otherwise edition-specific. Software can be packaged and installed many different ways, some of which do not support unattended installation. It's not always clear whether a package is installed at all. It's usually difficult to repackage software that doesn't work the way you want it to, and even if it's easy to do you probably can't redistribute the result.

So yeah, in general, package management is the ugly.

Re: Moving away from Puppet: SaltStack or Ansible?

#56

Post by eropple »

tootie wrote: post #54
GregorStocks wrote: post #53

Earlier quoted context omitted.

When you're managing more than a handful of servers, you very quickly start wanting to be able to run the same command on multiple machines - "upgrade all my API boxes to the not-vulnerable nginx", for instance, or "push this binary out to all my database servers". These sorts of services make that straightforward, and generally provide a large library of prewritten modules to do moderately-complicated things without…

Well, I've done that just using remote shell commands. And I'd have an easier time reading someone else's bash than I would their ansible whatevers. Is it actually more concise?

When written correctly, it's idempotent. I've done a lot of server management with bash and it's a lot easier to achieve idempotency with something like Chef.

Re: Moving away from Puppet: SaltStack or Ansible?

#57

Post by rb2k_ »

tootie wrote: post #54
GregorStocks wrote: post #53

Earlier quoted context omitted.

When you're managing more than a handful of servers, you very quickly start wanting to be able to run the same command on multiple machines - "upgrade all my API boxes to the not-vulnerable nginx", for instance, or "push this binary out to all my database servers". These sorts of services make that straightforward, and generally provide a large library of prewritten modules to do moderately-complicated things without…

Well, I've done that just using remote shell commands. And I'd have an easier time reading someone else's bash than I would their ansible whatevers. Is it actually more concise?

What if you have to upgrade a software package and add a new config file that is different on every server. I guess you can do that via a horrible sed command, but having native template support with variables is pretty nice.

Same for things like "tune the amount of worker processes depending on the amount of CPU cores the machine in question has".

Re: Moving away from Puppet: SaltStack or Ansible?

#58

Post by larrywright »

dgallagher wrote: post #12

Does anyone have experience using Configuration Management software in a heterogeneous environment? For example, I've seen large environments running Windows 2008/2008R2/2012/2012R2, various flavors and versions of Linux including Ubuntu Server, CentOS, SUSE, etc... What's the pretty? What's the ugly? I understand consolidation and standardization of operating systems is usually the best state to be in, but in a lot…

I work for a cloud service provider, and we use Chef in a heterogeneous environment. Several flavors of Linux, and Windows 2003-2012 (both 32 and 64 bit). The pretty is that Chef supports Windows very well, and the mature community cookbooks have good support for Windows as well. The ugly is that it makes testing more complex, but things like ChefSpec and ServerSpec + TestKitchen and Jenkins make it possible to release robust code.

The other CM software may have good Windows support as well, but I don't have any direct experience with it. Either way, the testing is the more critical component here, no matter what CM platform you choose.

Re: Moving away from Puppet: SaltStack or Ansible?

#59

Post by volume »

mpdehaan2 wrote: post #30
bkeroack wrote: post #19

Earlier quoted context omitted.

We are very heterogenous--something like 60/40 Windows/Linux split. Traditional Windows folks don't really use configuration management or even have any clue about it. Or at least that's my impression. I'm a Linux guy and have been fighting a one-man battle to CM-ize our infrastructure. I have no interest in using Microsoft's DSC on the Windows side (their brand-new CM-like solution in PowerShell) and something else…

Here's a blog about Ansible windows support for those interested: http://www.ansible.com/blog/windows-is-coming 1.7 comes out this week, and we're going to continue to improve it in 1.8.

I'm eagerly awaiting when the SSL cert setup is more streamlined and maybe encapsulated if possible?

I could hack away at the powershell that MS makes available but if you guys are going to put work into it, I will wait even more eagerly for it.

Re: Moving away from Puppet: SaltStack or Ansible?

#60

Post by ayrx »

tootie wrote: post #54
GregorStocks wrote: post #53

Earlier quoted context omitted.

When you're managing more than a handful of servers, you very quickly start wanting to be able to run the same command on multiple machines - "upgrade all my API boxes to the not-vulnerable nginx", for instance, or "push this binary out to all my database servers". These sorts of services make that straightforward, and generally provide a large library of prewritten modules to do moderately-complicated things without…

Well, I've done that just using remote shell commands. And I'd have an easier time reading someone else's bash than I would their ansible whatevers. Is it actually more concise?

Things like Ansible/Salt and similar tools cut out a lot of the boilerplate. There are also plenty of modules you can reuse without having to roll your own. You can achieve the same results using Bash/Perl/Python but a lot more effort is needed.
Post reply on HN