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

161–170 of 182 posts

Re: Moving away from Puppet: SaltStack or Ansible?

#161

Post by JustinGarrison »

mjfisher wrote: post #110
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…

> It's lightyears better than Puppet/Chef, and I am glad both exist. :) I'm pretty new to the world of CM, and have just started playing around with Chef and Vagrant. I've been pleasantly surprised by the utility of Chef (i.e. miles better than setting up machines by hand or shell script and worth the learning curve). Are there any particular areas of weakness when compared to Ansible/Salt/etc.? I've read a few Chef…

From experience here is some of the CM tool downsides that might help you

Chef - Ruby DSL is hard if you don't know Ruby. Lots of infrastructure to manage (if not using hosted Chef). On the fly orchestration requires 3rd party tools or Enterprise License.

Puppet - Custom DSL is json-y which for some is easier than Ruby. Scaling problems because puppetmaster compiles the manifests (instead of having nodes compile). 2 tools/interfaces for config vs orchestration (mcollective) gets confusing and not very consistent with features.

Ansible - pretty much a lot of what the article said. A bit slow and custom loops/dsl sometimes gets confusing. Managing hosts file is mostly the only "infrastructure" you need, but still is annoying. No Windows support (yet)

Salt - Not as mature so it can't do some advanced stuff Puppet/Chef can do. Last I looked at web UI (Halite) it was not much to look at. Hardly any integration into 3rd party tools (most favor Puppet)

Don't get me wrong, I love CM tools and the pros list would be 1000x longer than cons. But they all have some big downsides that hopefully will get better in the future.

Re: Moving away from Puppet: SaltStack or Ansible?

#162

Post by carlivar »

KaiserPro wrote: post #96

Having deployed salt to a medium sized cluster ~1500 farm machines, and around 1500 desktops, the one thing that salt won't do is scale. Salt has a lovely system where clients attach themselves to a zeromq and listen for commands. However after about 500 clients it starts to fail silently and not all clients update properly. The way we get round it is to run salt-call on the client at specific intervals. The other an…

We have 2700 machines using a single Salt master.

You have to tune it or you have the "thundering herd" problem. There are two parameters if I recall:

* a delay between master queries.

* randomization of when to check with the master.

You have to get pretty liberal with these values to scale out, but I assure you, it does work.

Re: Moving away from Puppet: SaltStack or Ansible?

#163

Post by carlivar »

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.

Salt's REAT protocol uses the CurveCP crypto library, so yes, this is being addressed.

Re: Moving away from Puppet: SaltStack or Ansible?

#165

Post by mpdehaan2 »

JustinGarrison wrote: post #161
mjfisher wrote: post #110

Earlier quoted context omitted.

> It's lightyears better than Puppet/Chef, and I am glad both exist. :) I'm pretty new to the world of CM, and have just started playing around with Chef and Vagrant. I've been pleasantly surprised by the utility of Chef (i.e. miles better than setting up machines by hand or shell script and worth the learning curve). Are there any particular areas of weakness when compared to Ansible/Salt/etc.? I've read a few Chef…

From experience here is some of the CM tool downsides that might help you Chef - Ruby DSL is hard if you don't know Ruby. Lots of infrastructure to manage (if not using hosted Chef). On the fly orchestration requires 3rd party tools or Enterprise License. Puppet - Custom DSL is json-y which for some is easier than Ruby. Scaling problems because puppetmaster compiles the manifests (instead of having nodes compile). 2…

Sorry to keep replying to this one - slight correction on recent Ansible windows support if interested:

http://docs.ansible.com/intro_windows.html

Re: Moving away from Puppet: SaltStack or Ansible?

#166

Post by e12e »

carlivar wrote: post #163
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.

Salt's REAT protocol uses the CurveCP crypto library, so yes, this is being addressed.

So, is being addressed not has been addressed? Is REAT the future of Salt? The most relevant I could find wasn't very clear:

https://groups.google.com/forum/#!topic/salt-users/nh8MqRiHV...

As far as I can tell RAET is still optional/Beta?:

http://docs.saltstack.com/en/latest/topics/releases/2014.7.0...

I tried finding out if CVEs had been assigned to the AES/RSA issues, but as far as I can tell there weren't any CVEs assigned:

http://www.cvedetails.com/vulnerability-list/vendor_id-12943...

Mail suggesting CVE for RSA exponent: http://www.openwall.com/lists/oss-security/2013/07/01/1

But the CVE is only reserved, not assigned?: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-2228

With the history of some very serious issues with the salt crypto, I'm a little concerned that there doesn't seem to exist any good documentation on the past and current state of the protocol security from the salt project?

As I said up-thread -- perhaps I'm not being fair, perhaps I'm just not aware of where to look -- but I've yet to see anything that puts me entirely at ease: have new members been added to the team? Has there been a successful audit? Did the attacks turn out to not be practical?

While I might not have the same confidence in paramiko as I do in openssh -- at least it works with a well-tested protocol -- and more importantly -- with a rather well-known protocol -- it's easier to evaluate. If someone can get root access via ssh that is bad. If the risk is limited to someone stealing a private key, then that is at least something to plan around (and make decisions around).

Re: Moving away from Puppet: SaltStack or Ansible?

#168

Post by sandGorgon »

ryan_lane wrote: post #156
carlivar wrote: post #146

Earlier quoted context omitted.

"the problem of orchestrating a bunch of Docker machines is still unsolved." I don't know about that. Mesos was already mentioned: http://mesos.apache.org/ There's also Kubernetes which has recently started working on Fedora and CoreOS: https://github.com/GoogleCloudPlatform/kubernetes And there is CoreOS's fleet system, although this is more low level and would still need orchestration: https://github.com/coreos/fle…

Kubernetes is built using SaltStack :)

interesting !

I didnt know that, but this confirms it - https://github.com/GoogleCloudPlatform/kubernetes/blob/maste...

Re: Moving away from Puppet: SaltStack or Ansible?

#169

Post by sandGorgon »

carlivar wrote: post #146
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…

"the problem of orchestrating a bunch of Docker machines is still unsolved." I don't know about that. Mesos was already mentioned: http://mesos.apache.org/ There's also Kubernetes which has recently started working on Fedora and CoreOS: https://github.com/GoogleCloudPlatform/kubernetes And there is CoreOS's fleet system, although this is more low level and would still need orchestration: https://github.com/coreos/fle…

True, but they are unviable for most startups. most of the solutions outlined here are very, very heavy. I'm a 2 man startup and really cannot invest into mesos to deploy a 4 VM cluster.

But the news that Kubernetes is leveraging SaltStack is hopeful.

Re: Moving away from Puppet: SaltStack or Ansible?

#170

Post by sandGorgon »

stonith wrote: post #83
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…

You might be interested in the Openstack deployment tooling called 'tripleo'[1] which has similar questions and has avoided all the current config management tools. The general gist is that what you're describing can be done using tools like Cloudformation/Heat or the newly minted Terraform, since they can both orchestrate the hardware/cloud resources and pass data in/out of the guests. [1] https://wiki.openstack.org…

thanks for this - but it looks to be tied to openstack, while I'm looking for something that leverages docker
Post reply on HN