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

151–160 of 182 posts

Re: Moving away from Puppet: SaltStack or Ansible?

#151

Post by geerlingguy »

ransom1538 wrote: post #137

I probably am dating myself here. But with cloud infrastructure what is the point of these configuration management tools? To get the configuration of an instance just fire up a copy of instance. To install something new, have a script install it on one manchine - monitor it, then start deploying it. You have versions of instances, backups, and exact copies. If you want to push, it is 10 lines of bash with a git pull…

This is also more of the 'containerized'/Docker-like infrastructure development workflow.

Tools like Ansible and SaltStack also provide pretty robust infrastructure orchestration/management tools that are conveniently provider-agnostic. I save a ton of money by spreading out servers for one particular service over a bunch of lower-cost providers (rather than AWS), and use Ansible to manage them all.

If you play in one particular cloud infrastructure, image-based configuration and provisioning may work fine, but if you need to support the movement of images from developer workstations through to different hosting providers (whether using Docker, CM, or bash scripts), Ansible can help with that (as can Packer, Terraform, etc.).

Re: Moving away from Puppet: SaltStack or Ansible?

#152

Post by ryan_lane »

wldlyinaccurate wrote: post #93

Everybody seems to be taking about moving away from Puppet lately. Maybe I just don't do anything sufficiently complex with it, but I've never had any problems or gripes with Puppet. 99% of the time it seems like the thing I want to do has already been done in a well-written module on the forge. The author seems to cite two main reasons for wanting to move away from Puppet: their codebase was large and badly structur…

There's definitely more reasons. I didn't want to detract too much from the topic of the blog post when I wrote it, since the post is already obscenely long.

Puppet doesn't have native support for a lot of things, which require us to either implement it in puppet's DSL, or in custom ruby, which the upstream won't take. For instance: git, gems, pip, virtualenv, npm, etc. etc..

Puppet doesn't have looping. I'm always told: "Iteration is evil. Puppet is a declarative language and if you're needing to loop you're doing something wrong." But it's simply not true. Looping making things insanely simpler.

Puppet isn't executed in order, even for the same service in the same environment across systems. You have to very diligently manage every require for ordering, and no one does it right. This had lead to systems unable to run first runs really often, which causes problems with autoscaling. I don't enjoy spending my time cleaning this up often.

Puppet's DSL is full of little gotchas that constantly cause issues for developers who aren't very familiar with Puppet.

Half of our team was very familiar with Puppet. If you look at my blog, quite a few of the older posts are about Puppet. I worked on the puppet infrastructure at Wikimedia Foundation for a long time, and released all of the puppet code as open source (they have 60k+ lines of puppet).

Re: Moving away from Puppet: SaltStack or Ansible?

#153

Post by dkarapetyan »

malraux wrote: post #132
dkarapetyan wrote: post #84

Earlier quoted context omitted.

Salt is also ok I think. I don't quite understand custom DSLs though for configuration management. Giving users a library of idempotent code components like chef does I think is way better than a custom language that is almost but not quite or maybe turing complete. At some point you are going to want to iterate and loop over stuff and if there is anything that ant has taught us is that imperative things are better h…

When that happens for me in Ansible I just drop into Python and write a custom module. They're pretty straightforward.

The benefit with Chef is that it is always Ruby. There is no dropping in/out of anything other than Ruby. As a Ruby programmer I quite like that. It doesn't fight the language it is embedded in and uses all the language idioms to great effect.

Re: Moving away from Puppet: SaltStack or Ansible?

#154

Post by ryan_lane »

VLM wrote: post #131
wldlyinaccurate wrote: post #93

Everybody seems to be taking about moving away from Puppet lately. Maybe I just don't do anything sufficiently complex with it, but I've never had any problems or gripes with Puppet. 99% of the time it seems like the thing I want to do has already been done in a well-written module on the forge. The author seems to cite two main reasons for wanting to move away from Puppet: their codebase was large and badly structur…

The cool kids have a new fad so you're not cool unless you dump puppet. No technical reason at all as near as I can see. Its pretty much the same as "Perl hate", why do we hate Perl? No reason at all, other then being cool means hating Perl! Very middle school social dynamic. My puppet manifests is 16K. My modules is larger but I've got some large files stuck in there (long story) There are meta questions like: What…

I have a category on my blog dedicated to LDAP: http://ryandlane.com/blog/category/ldap/ I used it very heavily at Wikimedia and had very nice integration with Puppet. In general I think it's good to avoid LDAP if possible. It adds a point of failure and assuming you're not managing thousands of users (we were handling about 5k users in Wikimedia Labs), it's generally more work than managing users in Salt/Ansible/Puppet.

We didn't save a lot of lines of code replacing the user/group code with Salt. We saved a lot of lines of code by using native support for git/pip/virtualenv/npm/etc, which were implemented as a mix of custom puppet DSL and ruby.

We could have likely saved 3-5k lines of code from a puppet rewrite from scratch, but it still wouldn't have been as simple as the Salt or Ansible code.

Re: Moving away from Puppet: SaltStack or Ansible?

#155

Post by zimbatm »

mpdehaan2 wrote: post #113
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.

> 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.

It's good but I wouldn't describe this as fast, it should be possible to increase the performance by another order of magnitude with some optimisation. Web servers can easily serve 5000 request per second even when SSL is involved, why couldn't Ansible do the same ?

After enabling ControlPersist, the next optimisation is to run Ansible in the same datacenter. Latency is a killer when deploying to us-east-1 from Europe.

> Steps are executed in order, but that's true of all CMS systems.

It's true on a single host (although puppet's and salt's ordering is not guaranteed). Ansible also orders across all the hosts. If you have tasks A->B->C, ansible will first run A on all the hosts and collect the results before moving to the next step. Each step is thus as slow as the slowest execution.

Re: Moving away from Puppet: SaltStack or Ansible?

#156

Post by ryan_lane »

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…

Kubernetes is built using SaltStack :)

Re: Moving away from Puppet: SaltStack or Ansible?

#157

Post by ahpook »

ryan_lane wrote: post #152
wldlyinaccurate wrote: post #93

Everybody seems to be taking about moving away from Puppet lately. Maybe I just don't do anything sufficiently complex with it, but I've never had any problems or gripes with Puppet. 99% of the time it seems like the thing I want to do has already been done in a well-written module on the forge. The author seems to cite two main reasons for wanting to move away from Puppet: their codebase was large and badly structur…

There's definitely more reasons. I didn't want to detract too much from the topic of the blog post when I wrote it, since the post is already obscenely long. Puppet doesn't have native support for a lot of things, which require us to either implement it in puppet's DSL, or in custom ruby, which the upstream won't take. For instance: git, gems, pip, virtualenv, npm, etc. etc.. Puppet doesn't have looping. I'm always t…

I'm a little sad because most of these issues (as I understand your description them) are already fixed or well underway :( It's probably too late for your specific case but I'd like to reply anyway since a lot of this is "conventional wisdom" based on old information. Full disclosure: I'm the product owner for Puppet and before I worked here, I ran it in large-scale production since 2008.

Not quite sure what you mean by 'native support', but gem and pip package providers are built-in. there are high-quality modules for git (puppetlabs-vcsrepo), virtualenv (stankevich-python), npm (puppetlabs-nodejs), etc -- it's a design decision to move much of this into modules and out of core so they can iterate faster.

Totally agree that loops make many language constructs much easier, and there's looping in the rewritten parser -- https://docs.puppetlabs.com/puppet/3.6/reference/experiments... -- which will be on by default in the next semver major.

While the model definitely wants you to describe relationships between resources if you need to send subscribe/refresh messages, there's toggle-able ordering algorithms that will let you run them in manifest order -- I blogged about it here: http://puppetlabs.com/blog/introducing-manifest-ordered-reso...

The parser and evaluator are undergoing a total rewrite to be an expression based grammar, which is explicitly to make better definition around the language and eliminate the gotchas -- https://docs.puppetlabs.com/puppet/3.6/reference/experiments... (this will also be the default on the next semver major)

--eric0 / @ahpook

Re: Moving away from Puppet: SaltStack or Ansible?

#158

Post by ferventcoder »

dkarapetyan wrote: post #86
Kiro wrote: post #80

May I ask why people think Puppet sucks?

It layers a custom DSL on top of a perfectly adequate language, uses standard terms like classes in non-standard ways, takes away the linear top/down flow that most programmers are used to, forces sequencing through notification chains, steamrolls over error messages willy-nilly, etc. Although I'm a bit biased so a few more data points would be helpful.

And the linear top/down flow, also known as manifest ordering, is now available with Puppet. See http://puppetlabs.com/blog/introducing-manifest-ordered-reso...

Re: Moving away from Puppet: SaltStack or Ansible?

#159

Post by ryan_lane »

KaiserPro wrote: post #107
mianos wrote: post #104

Earlier quoted context omitted.

I would post a bug report. I know linkedin has over 10k nodes with saltstack. Thomas was there tuning it so I'm sure it should work.

its something they know about. The current workaround is multiple masters, which isn't entirely practical

Wikimedia runs 1,000+ nodes on a really small box. No need for multiple masters. Just increase your worker threads.

Re: Moving away from Puppet: SaltStack or Ansible?

#160

Post by scott_karana »

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…

Wouldn't it still make sense to use a configuration management for automated building of docker containers?
Post reply on HN