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

31–40 of 182 posts

Re: Moving away from Puppet: SaltStack or Ansible?

#31

Post by existencebox »

bkeroack wrote: post #19
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…

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…

Mm, I'd say you're right on about some things, but slightly off the mark on others. Traditional windows folks certainly know at least some things about CMS, or rather, CM like functionality. WMI/WDS and friends are surprisingly robust when it comes to things like provisioning and patching, and powershell has been (and I say this as a primarily linux weenie) a breath of fresh air in the windows ecosystem, although I can't speak for its capability specifically as a CM utility. What I'd say is true is that windows folks don't typically know about linux CM, and visa versa. (At least, I certainly didn't know squat about windows CM when I started working in a heterogeneous system).

We made a similar choice as you did, going with salt for certain functionality (because as you found, weird edge cases/fragility of salt on windows) but at the root of things, you use the tool that works well for the system. And in some situations, that means living in a bipartisan world (WDS for windows deployment, spacewalk for linux) or looking for a solution that plays well in the sandbox with both (well), which is a bit rarer, ala salt.

I'm sure there are people who solved this problem way more elegantly, but for being pretty damn understaffed and new to devops when we started, it worked surprisingly well by the end of things :)

Re: Moving away from Puppet: SaltStack or Ansible?

#32

Post by ryan_lane »

vacri wrote: post #18
zhynn wrote: post #15

While I have been a happy Ansible user for some time, the criticisims that the author pointed out that really resonated with me were: - Ansible is slow even when it doesn't have anything to do. This is true. For example, we manage lists of former users that should not exist on systems, this gets quite slow. I think that the slowness is mostly due to SSH, but it could be smarter about bulk operations, I suppose. - Cus…

If you think ssh negotiation is the slow point with ssh, have a look into 'persistent connections' The below is an example setup of a session that persists for ten minutes after last logout. Subsequent ssh attempts (or new parallel ssh attempts) will piggyback onto the session and avoid the renegotiation delay. host * ControlPersist 10m ControlPath ~/.ssh/master-%r@%n:%p ControlMaster auto

Hi. I'm the blog post author. The issue isn't SSH. I was running ansible-playbook on the local system using -c local. It wasn't using SSH at all.

Re: Moving away from Puppet: SaltStack or Ansible?

#33

Post by mpdehaan2 »

andyl wrote: post #20

I've had experience with Chef, Puppet and Ansible. Ansible is the least complex, and we're using it daily. Re: Ansible community dynamic - I've gotten unfriendly feedback a few times and agree with the negative reputation. Aside from community, Ansible is a big step up, and I suspect Salt would be as well.

I'm sorry you thought we were unfriendly.

Don't read too much into responses if we don't go out of our way to say "Hi yall", but we do try to say thank you a giant ton.

We're pushing an IRC channel of about 800 people now, and I think we're mostly just trying to be concise in the waves of giant teaming hordes of Ansible users :)

If you don't let that get under your skin, you'll be fine! We're happy everyone is here, usually. Though we'll also share when the design decision of something is that way for a reason.

As it is said, "go not to the elves for council, for they shall say both no and yes" :)

Mostly we're just trying to get you on your feet as quickly as possible.

Try the tool, by all means, if we're ever short, it's because we're so incredibly busy, and we're thankful for every user we have.

Re: Moving away from Puppet: SaltStack or Ansible?

#34

Post by mpdehaan2 »

dcosson wrote: post #21
anko wrote: post #14

Earlier quoted context omitted.

I've never heard of ansible being referred to as a new generation. What do you think defines this generation? I use puppet and chef a fair bit so I'm just curious on the new features offered.

My take is that this "newer generation" of tools seems to focus on combining configuration management with orchestration. Chef and Puppet let you define the static state of the world but leave it up to you to figure out how to transition when something needs to change. On the other hand, Ansible works well as simply a remote task runner (like Fabric). Salt is the one I have least experience with, but I had a conversa…

I'm not finding the new generation term particularly meaningful.

One thing that was somewhat unique about Ansible was it was designed for rolling updates as the initial use case, and the desire to solve deployment problems rather than just CM problems.

Everybody tends to view orchestration differently, so see our take:

http://www.ansible.com/blog/orchestration-you-keep-using-tha...

and

http://www.ansible.com/blog/2013/11/29/ansibles-architecture...

Ultimately, for us, it meant boiling back a lot of things to base concepts, and taking parts we liked from a lot of different things.

But is there a generation? I don't think so.

Some models make things a bit more or less flexible, or allow different capabilities.

Re: Moving away from Puppet: SaltStack or Ansible?

#35

Post by ryan_lane »

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 other than me to fix.

It's generally considered a rude response in the open source world because it's telling users they aren't worth your time. It's a warning sign of an unfriendly upstream.

Re: Moving away from Puppet: SaltStack or Ansible?

#36

Post by mpdehaan2 »

willthames wrote: post #17
mpdehaan2 wrote: post #5

Hi ansible author here! This was definitely an interesting comparison but to correct a few misconceptions: Ansible has 810 contributors at this point. I'd love to say I wrote everything but it's a huge shared effort. We also have a lot of mods other projects don't, so some comparison aspects were not even. We do say no when we disagree. I think that's important. Filtering and testing makes a project what it is to a d…

This seems illuminating. "The only complaint that I have here [about Salt] is that they are sometimes less rigorous than they should be when it comes to accepting code (I’d like to see more code review)." Keeping high quality across a project requires discipline. And that discipline can sometimes seem cold. "pull request welcome" is at the warm end of the spectrum.

Yeah I don't think we've ever meant "pull requests are welcome" as a "screw you guys!". We actually mean it's welcome.

When we don't want something, it's more like "I don't think we are interested in that feature".

The big green web merge button on Github is a scary beast, and if we risk a few users for stability and taking our time, I'm cool with that. I think a lot about running a successful project is working with a contributor and helping them get the pull request into good shape.

Those that can deal with the process and power through it become better contributors for later.

We want to very much avoid being Wikipedia, while still being a canvas for massively widescale contributions.

anyway, stability to us is very important. Security and usability (and docs) are important. Those things come first before we take on new features.

Will and I disagree from time to time, but in the end, we're both way better for it, and he keeps me honest.

Anyway, for those reading the article - read all commentary, and try both. Try Puppet and Chef too. If you like Ruby, you might really dig Chef even, and we're ok with that. It's all good and there's plenty of users to go around :)

Re: Moving away from Puppet: SaltStack or Ansible?

#37

Post by ryan_lane »

mmerickel wrote: post #8

It's unfortunate that this article focuses on running the playbooks/salt states locally. The use of ssh by ansible was the killer feature for me. Configuring a remote cluster without requiring a persistent master. There are valid arguments for maintaining a persistent master, but it's just not in the cards sometimes. I know salt-ssh exists but it's still alpha, I look forward to seeing how it pans out and whether it…

I'll follow-up with a post about how we're working without a master. We need neither SSH, nor a master.

We're very heavily using autoscaling, which makes SSH a no-go. Ansible has Tower for this, but it's proprietary. We /could/ use a salt master for autoscaling, but we prefer masterless in this situation because it scales better.

Re: Moving away from Puppet: SaltStack or Ansible?

#38

Post by otoburb »

wldcordeiro wrote: post #7

Interesting article but the design of the site made reading it give me a headache. I recently also made a move as well, went from Chef to Ansible and I am really happy I did. Chef was a pain.

We're soon going to be evaluating various configuration management frameworks. Could you outline a few points why Chef was considered a pain?

Re: Moving away from Puppet: SaltStack or Ansible?

#39

Post by mpdehaan2 »

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…

Hi Ryan,

I'm sorry you feel that way. In our case, we get a TON of bug report traffic - many are just user questions which we'll direct to the list, some are just nice to haves, we file most of the good ones, but not always.

Though I would consider performance tuning of the user module not a bug, and I do not think the newline behavior of copying the file on the filesystem was a bug either.

A discussion on ansible-project would have been welcome after you felt we had taken the wrong track, but when we feel some requests aren't worth our time, it's because we have a huge audience to serve and are triaging everything.

We feel it would have been unfair to you to let it sit infinitely when we were unlikely to spend time on it.

Re: Moving away from Puppet: SaltStack or Ansible?

#40

Post by mpdehaan2 »

ryan_lane wrote: post #37
mmerickel wrote: post #8

It's unfortunate that this article focuses on running the playbooks/salt states locally. The use of ssh by ansible was the killer feature for me. Configuring a remote cluster without requiring a persistent master. There are valid arguments for maintaining a persistent master, but it's just not in the cards sometimes. I know salt-ssh exists but it's still alpha, I look forward to seeing how it pans out and whether it…

I'll follow-up with a post about how we're working without a master. We need neither SSH, nor a master. We're very heavily using autoscaling, which makes SSH a no-go. Ansible has Tower for this, but it's proprietary. We /could/ use a salt master for autoscaling, but we prefer masterless in this situation because it scales better.

ansible-pull is available for those that need to invert the architecture, though we're finding most users in companies who need autoscaling can afford Tower. Price points are definitely important in that regard, but ansible-pull does exist for those that would rather go the pure OSS route.

Tower is also free for up to 10 nodes. See my comments above about why we went that route - being able to build products versus having to become a consultancy or support outfit makes it easy to keep ansible to be easy to understand and rock solid, and most people are quite happy with that split.

Post reply on HN