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

111–120 of 182 posts

Re: Moving away from Puppet: SaltStack or Ansible?

#111

Post by buro9 »

wernerb wrote: post #101
buro9 wrote: post #98

I look for two things when considering configuration tools. 1. How does it handle cross-cutting concerns? 2. How does it handle complex configuration files? For the cross-cutting concerns I use the firewall as an example. I look to see how multiple projects and modules (that are going to be installed on a machine) can declare their firewall rules. I'm a Puppet user presently, but a quick look says that Ansible has gr…

Any (configuration)file can be installed and/or templated with both Ansible and Salt. This includes whatever Nginx has for configuration. I'm not 100% with both, but I guess you have nginx be installed in some dedicated pillar/playbook and you can have your application pillar/playbook include templated configuration files to be inserted into /etc/nginx/conf.d and notify the service to be reloaded somehow.

That much I know.

But when it's clearly a scenario that everyone using Nginx will be writing these templates, surely it's better to have a well maintained master copy of them.

The complexity usually comes in having multiple projects wanting to modify the template(s) to wire themselves up.

A good sign for config tools is a feature rich and well maintained recipe/playbook (whatever you want to call it) that is able to do the non-trivial things (most deploy scripts for nginx don't seem to deal with SSL particularly elegantly with all of the options involved).

Puppet does well at this, but I dislike the heavy dependencies that some of the modules have. For example if you just wanted to install nginx you're going to end up here: https://github.com/jfryman/puppet-nginx and will discover that you have dependencies https://github.com/jfryman/puppet-nginx/blob/master/Modulefi... and will also need to install: https://github.com/puppetlabs/puppetlabs-concat https://github.com/puppetlabs/puppetlabs-apt and https://github.com/puppetlabs/puppetlabs-stdlib . One of which has their build failing.

What I look for in a config tool is such good defaults for handling these complex (but commonplace) scenarios, that the recipes/modules/playbooks are mature, dependency-free and well-maintained.

I guess I'm spoiled by programming in Go, I've got used to the idea that the language includes a stdlib comprehensive enough that 90% of what you need (even with those complex things like "give me a web server") is all built in.

That's the problem I'm trying to solve whenever I consider abandoning Puppet... dependency hell.

But I also remember the pains when I first used Puppet: cross-cutting concerns and complex configurations.

Re: Moving away from Puppet: SaltStack or Ansible?

#112

Post by zimbatm »

I have used Ansible 6 months ago and it felt slow.

The biggest issue which is intrinsic to the model is that each task is executed sequentially across all the target hosts. It makes it's behaviour easy to understand but it also makes each step as slow as the slowest host.

Another issue that might be fixed now is that each task is essentially a script uploaded to the target and then executed locally. Unfortunately at the time the scripts weren't cached properly so N invocation of the same task would mean N uploads of the same script.

That being said it's really simple to use and I recommend it if you don't have an existing infrastructure management system. Ansible fits in well as an orchestration tool.

Re: Moving away from Puppet: SaltStack or Ansible?

#113

Post by mpdehaan2 »

zimbatm wrote: post #112

I have used Ansible 6 months ago and it felt slow. The biggest issue which is intrinsic to the model is that each task is executed sequentially across all the target hosts. It makes it's behaviour easy to understand but it also makes each step as slow as the slowest host. Another issue that might be fixed now is that each task is essentially a script uploaded to the target and then executed locally. Unfortunately at…

Hi zimbatm,

Please read the tuning article on the blog for sure. It's definitely not slow and we have folks updating 5000 servers in 5 minutes. (Yes, really!) ControlPersist and the like are key, and we'd be happy to help discuss options for you.

As for sequentially, set --forks to control parallelism. Steps are executed in order, but that's true of all CMS systems.

Re: Moving away from Puppet: SaltStack or Ansible?

#114

Post by mpdehaan2 »

zwischenzug wrote: post #109
darklajid wrote: post #76

I haven't looked at Salt, but I had a love/hate relationship with Ansible so far. To be clear: Starting with Ansible was amazing, the first couple steps were easy and enlightening. Maybe I'm expecting too much now and act entitled or something? That said, it broke down rather quickly. - My first issue was documentation. This article is correct about the current state of the documentation, but the site was in a really…

"Everything I try to do in Ansible seems to turn into a shell script" This was my disappointment with Ansible (and other CM tools) - so why not treat the shell as the basic unit of action? See my post elsewhere on this page for more: https://news.ycombinator.com/item?id=8135823

This doesn't have to be the case.

All resources in Ansible are declarative models of state, that get informed, and have idempotent properties.

So it's just like any CMS.

However if you want to write a deployment script, it also lets you, rather than fighting it kicking and screaming :)

Also, when you want to just push and run a script versus using one of the 234 other modules, it's there - http://docs.ansible.com/script_module.html

Re: Moving away from Puppet: SaltStack or Ansible?

#115

Post by mpdehaan2 »

maslam wrote: post #77
darklajid wrote: post #76

I haven't looked at Salt, but I had a love/hate relationship with Ansible so far. To be clear: Starting with Ansible was amazing, the first couple steps were easy and enlightening. Maybe I'm expecting too much now and act entitled or something? That said, it broke down rather quickly. - My first issue was documentation. This article is correct about the current state of the documentation, but the site was in a really…

Ansible is nice, but I share the same gripes as darklajid. Plus, with Docker taking off, I question how valuable Ansible will be going forward. I see it as a "nice Chef" or "usable Puppet". Not revolutionary.

I don't think we're interested in creating a revolution, but making IT practices easier and simpler and better. Which has a LOT of merit.

With regard to Docker, see http://www.ansible.com/blog/2014/02/12/installing-and-buildi...

The overlap of Ansible and Docker is pretty stratospheric in adoption levels. As more fleet management services exist, to us, it looks like another VM type, and all those cloud modules will also help orchestrate it.

But now, people are using it for both image builds and placement in great number.

Re: Moving away from Puppet: SaltStack or Ansible?

#116

Post by mpdehaan2 »

sandGorgon wrote: post #81

I wish that Ansible would work with orchestrating Docker containers. Here's my thought - Docker is replacing the use case for using Ansible/Chef/Puppet for a lot of people. It is far too easy to build portable docker machines and deploy them on bare metal. For me, the use case of provisioning a softlayer server and then setting it up using Ansible/Chef is no longer present. However, the problem of orchestrating a bun…

Yep, it does to a great degree now - read http://www.ansible.com/blog/2014/02/12/installing-and-buildi... and can also be used to deploy containers.

As various "clouds" for Docker spawn up the various cloud modules will also be able to talk to these things.

Re: Moving away from Puppet: SaltStack or Ansible?

#117

Post by staz »

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…

This is not a problem of entitlement where people expect that you fix their bug for them. This is an anti pattern because many people consider this type of answer rude and it doesn't create a welcoming community.

Saying "This is a legitimate bug, but I don't care enough to fix this for you." is already an order of magnitude more polite than "Pull request welcome" or the older "Patch welcome" , explaining in details why and if necessary how open source work even more so. You have to remember than not every one know the Open Source community speak. If you can guide the reporter on how to create said pull request, even better.

Yes its take more works and it's less fun than hacking at code, but building a great community is a lot of works. It's also, for me at least, what separate good projects from great ones

Re: Moving away from Puppet: SaltStack or Ansible?

#118

Post by mpdehaan2 »

reality_czech wrote: post #100
mpdehaan2 wrote: post #43

Earlier quoted context omitted.

I think it's something that can be improved, yes. I'm not sure it's a bug, and I'm not sure it's really all that slow. We're talking about 0.5 seconds and maybe it could get down to 0.4? If you dig into the module I'm not sure what you would change. (Again, a fine discussion for ansible-devel probably? How would you solve it?) In your case, managing a list of 80 users to be sure there or not, I might have suggested p…

Ansible seems like a cool project... thanks for stopping by here. One question, though. 0.4 seconds seems like a very long time to query one user/group, though. You should be able to query thousans of UIDs a second, minimum... unless you're using LDAP and you have a slow network or something. You could write a simple C program to query a bunch of UIDs and I bet it wouldn't even take a millisecond to run. So where is…

it's definitely true that most of our users are deploying configs and applications so there's not a lot of user management, but the user management is definitely robust.

We're using GNU user tools in many cases for correctness and efficiency of not reinventing the wheel so you might wait a little more for them.

We're open to tuning but it's really not been a problem.

It's still statistical noise in the end, and, yeah, like we said, we've got more important things to work on first. It would be nice if we had time for everything, but this just doesn't rate in the grand scheme of things right now, still.

Someday, perhaps! Meanwhile, try things out, I don't think this will matter in practice for most folks :)

Re: Moving away from Puppet: SaltStack or Ansible?

#119

Post by mpdehaan2 »

e12e wrote: post #106

I've always been a bit wary of salt after: https://github.com/saltstack/salt/issues/2239 Perhaps unfairly so... yet, I'm not entirely put at ease by: https://github.com/saltstack/salt/issues/5913 Did salt ever move to a secure transport? Then there's the (linked above, inline) issue with RSA exponent.

http://shouldirollmyowncrypto.com/ ? :)

Note, had no part in registering this, but it's another example of why you don't want to hand-roll things.

Re: Moving away from Puppet: SaltStack or Ansible?

#120

Post by shiven »

Just wanted to say I love ansible!!! After the nightmare that was Puppet/Chef, ansible has been just what the doc ordered. I keep all my playbooks under version control (git) and deploy via ansible-playbook. KISS philosophy; it has worked out better than anything we used in the past.
Post reply on HN