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

21–30 of 182 posts

Re: Moving away from Puppet: SaltStack or Ansible?

#21

Post by dcosson »

anko wrote: post #14
mlieberman85 wrote: post #3

Personally a fan of Ansible, but I've also been pretty impressed by SaltStack as well. Either is much simpler and easier to use than the older generations of configuration management tools (cfengine, Puppet, Chef.)

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 conversation with the creator once and he seemed excited about the orchestration possibilities with Salt. If I understand correctly you can react to events that get triggered either manually or based on a condition on some other server you're managing. So both of these tools make it easy/natural to do something like run a rolling restart of a group of servers.

Re: Moving away from Puppet: SaltStack or Ansible?

#22

Post by _Soulou »

I read that for some of you the Chef experience was painful. I'm using chef-solo with the chef-solo-search cookbook and everything is working pretty fluently. Each of my node owns the entire repository and apply chef-solo on itself. With a cron to periodically update the chef repository, it is really confortable.

I agree that using chef-server is a bit painful (that's why I don't), but otherwise there are a lot of cookbooks and it works well. What kind of bad experience did you get?

Re: Moving away from Puppet: SaltStack or Ansible?

#23

Post by existencebox »

harshreality wrote: post #9
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…

Salt devs don't have any reason to make salt-ssh a second-class citizen, because they're working on a third transport. Everything's going to be (mostly, already is) abstracted from the transport so that salt-ssh, zeromq, and raet (the new transport, a kind of hierarchical distribution of messages to deal with massive deployments where the zeromq one-master-to-all-minions setup has scaling problems) are interchangeabl…

This is good in theory, but in practice, there are known bugs against salt-ssh for which certain operations and states don't seem to work properly. (At least one of which I believe I pushed.) In hindsight (The problems I ran into with it were rather early into my multi year salt experience) it's highly possible in my naivety I was trying to do something that's simply not supported like tying some ext pillar in or something, but I have strong memories of bigger problems... (Wish I had a better recollection, but it's been a while)

The long and the short that this rambling was meant to convey: Salt is still very much in development. There are multiple open bugs on multiple core features (win repo comes to mind) which simply do not work as documented, period. That being said, when I made the same decision process for the company I was sysadminning for at the time as the author is considering, I went with salt, (with much the same background knowledge), and even knowing what I do post factum, I don't think I would change that decision. (I can give more justification as someone who had to live with their choice if anyone is curious, but I feel like I'm already rambling a bit.)

Re: Moving away from Puppet: SaltStack or Ansible?

#25

Post by mpdehaan2 »

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

Here's a rollup of lots of things you can tune:

http://www.ansible.com/blog/ansible-performance-tuning

Re: Moving away from Puppet: SaltStack or Ansible?

#27

Post by mpdehaan2 »

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…

So I think we do believe in teaching users the way to use the tool, rather than making every possible request in cases where things aren't clear. And that usually means making the docs self-convey what those ways are.

When you get to a project of Ansible's size, yes, we do have to be pragmatic about what we spend time on, so we like to look for patterns. if something gets heard from 15 times, it's definitely a thing. If something gets heard from once, we're most likely going to show the idiomatic way to do something in Ansible.

AnsibleWorks is actually not our company name, it's just "Ansible, Inc", and yes, our UI is closed source. But that allows us to hire a ton of people to work on it too, and I think we've made the right choice. I wanted our company to not become a support firm or a consultancy, and focus on products, such that we would always be motivated to keep the tool as easy to use as possible. The product thing is the natural place to take it in that case.

It's still free to use for 10 servers forever, and I think most of our users think we made the right choice there.

As for slowness, do check out the blogpost linked below, though upgrades for particular modules are always welcome.

I do think the custom DSL was 100% the right choice, as Ansible is a 100% valid data format, machine parseable, rather than something that only evaluates as YAML, and is not parseable.

Try "-v" if you'd like to see output without the debug, though the idea about having a "verbose: True" on the task might save some output. I'll think about that one.

Re: Moving away from Puppet: SaltStack or Ansible?

#28

Post by mpdehaan2 »

cheald wrote: post #13
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.

"Pull request welcome" usually means "This is a legitimate bug, but I don't care enough to fix this for you." Some people believe that maintainers should fix all bugs that are reported to them. Other people believe that the open-source nature of the software should cause people to fix their own bugs and contribute the fixes back to the project, and both camps often believe that demands on their own time and effort ar…

Fortunately it doesn't for us.

In our case, one of the things I want to do is run it as a fully legitimate open source project.

In this case, we're going to be open and say when we can't work on something, or when we're unlikely to work on something, because we've got those 800+ contributors at or door asking for things.

There's a lot of triage.

In the past I've seen other projects take a few alternate routes - leave everyone hanging (unfair) or auto-merge everything (unstable). So that's kind of where we're at.

We do recognize we don't have /limitless/ resources, but this is kind of what you get for having a project on GitHub with so many stars and forks.

The user and testing community is absolutely awesome, but I when we say we aren't going to do something, it's because we want to be clear where we stand or have a conversation, or encourage people to contribute.

As Spock said "the needs of the many, outweigh the needs of the few or the one". Triage!

Re: Moving away from Puppet: SaltStack or Ansible?

#29

Post by mpdehaan2 »

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…

Actually all modules take the key: value form if you want to use that :) ... though if you need to pass structured data, you can't use the shorthand.

Re: Moving away from Puppet: SaltStack or Ansible?

#30

Post by mpdehaan2 »

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…

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.

Post reply on HN