Live data from Hacker News

Moving away from Puppet: SaltStack or Ansible?

ryandlane.com

131–140 of 182 posts

Re: Moving away from Puppet: SaltStack or Ansible?

#131

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 are you doing with 15000 lines of puppet? I have a couple thousand and feel a bit over extended, like why am I doing this.

How are you replacing ten lines of puppet with 1 line of alternative when all I'm seeing in the examples is replacing 3 lines of

group { "logusers":

    ensure => "present",
}

with

- name: Ensure groups exist

  group: name={{ item.key }} gid={{ item.value.id }}

  with_dict: users
Like, where is the big win where those 3 lines of puppet are being turned into 0.3 lines of Ansible?

There is also the question of why I'd configure individual groups on individual machines instead of just tossing it in the LDAP once, probably by hand. Or distributing a system wide /etc/groups much as I used to share a division wide emergency /etc/hosts (like, this is the minimum /etc/hosts required to conveniently fix DNS if DNS breaks).

(edited to add actual numbers. I have ldap and getent group | wc -l reports 76 groups. I could replace that with 76 groups * 3 lines per group plus a blank line between entries = 304 lines of hand maintained code. But in 3 lines I could distribute a golden /etc/group to all machines. Or in a few more lines I could make all my machines use LDAP and get passwd and some other stuff centrally controlled for free (and yes I use ldap for passwd and no I use kerberos for auth, so passwd just holds home dirs and stuff like that). So I could write hundreds of lines of puppet to get out of editing one golden group file or get out of running ldap, but the alternatives are so much easier...)

There exists a meta question of allocation of resources. You can do "everything sysadmin" in puppet. Or make a universal does it all gold image that is well backed up and enables or disables parts of itself based on role and never automate its configuration at all, just spin up images and give them "special" hostnames and they sort themselves out. Or not automate trivial parts. Or place some weirder config stuff in a shell script technically not part of puppet other than being distributed, run, and tested for error free operation. Or a mix across all. So I could see a "gentoo-like" start with an official distro image and use nothing but puppet to do everything taking 15000 lines of code, maybe. But that sounds hard... do it a different way, no need for different tools.

Re: Moving away from Puppet: SaltStack or Ansible?

#132
post #82

IMO, Chef > Puppet > Ansible I wouldn't go near salt

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.

Re: Moving away from Puppet: SaltStack or Ansible?

#133

Earlier quoted context omitted.

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/scr…

is CMS supposed to mean Configuration Management System ? If so, that's a really awful re-use of a TLA (three letter acronym) Many people still refer to any website that is editable as a CMS - Content Management Systems. so please don't call it that, it will only sow confusion

The term CMS has been used to mean configuration management system for longer than it has been used to mean content management system. One can find articles from 1990 using it in the former context, while the latter appears to have been used since the late 1990s.

Re: Moving away from Puppet: SaltStack or Ansible?

#134
post #131

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…

"Its pretty much the same as "Perl hate", why do we hate Perl? No reason at all, other then being cool means hating Perl!"

Ummm, no. Believe me, having worked in a PERL shop for nearly 10 years, I was ecstatic to start working in Java (!). And I have zero regrets. It's nothing to do with being "cool" or any other pointless patronising insults to other developers. It's that badly written PERL is the worst excrement ever to have been smeared on a computer screen. Yes it can be clean, clear and readable, but only in the hands of an experienced expert (using "modern PERL", which only started to exist ~6-8 years ago) backed by stringent code review and consistent team practice. Without the infrastructure in place, you end up with reams of unmaintainable, slow, buggy, eye bleed code. I've seen plenty of PERL from plenty of projects and plenty of different developers in different institutions and companies and the vast, vast majority is crap.

The last bit of code I had to rewrite (5 years effort by a weak PERL coder, replaced in 3 months in Java, maintained by someone with no previous Java experience quite happily) would have made you cry. I have never seen anything like it in any language (note, I don't work with PHP either), and I don't believe such a steaming mess would be possible in any other modern programming language, let alone from someone who had been a professional programmer for 10 years.

To me, your attitude is the problem the PERL community has. The language deserved the bad reputation. Until modern PERL appeared, it was almost impossible for a beginner to produce anything like good code. It is possible now (I have seen beautiful clean PERL), but instead of trying to educate and bring people back to the fold, the community has a massive chip on its shoulder, refuses to admit the problems PERL has (still), or that it ever had any, and proceed to insult everyone else. If PERL hadn't learnt from the trends in other languages (esp a decent OO system, Moose), it would be literally dead by now.

Re: Moving away from Puppet: SaltStack or Ansible?

#135
post #38

Earlier quoted context omitted.

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

My major pain point was the complexity of Chef Cookbooks in comparison to Ansible Playbooks. I could hardly wrap my mind around how to write my own Cookbooks after exploring some of the ones I used (Ruby, rbenv, Git, Nginx.) Another major thing for me at least was the documentation, it seemed like Ansible had better documentation to me vs Chef. Finally another thing was the product offerings of Chef vs Ansible. Chef…

I'll be on the lookout for these items in the evaluation results. Thanks!

Re: Moving away from Puppet: SaltStack or Ansible?

#136

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…

Had the same thought. Puppet code was bad and no one knew Puppet. Seems like a fine reason to move. But could be the other way around. Could be Ansible code is bad, no one knows it, lets move to Puppet!

Re: Moving away from Puppet: SaltStack or Ansible?

#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 and ssh public keys. AWS has an amazing API. I have seen guys try these 9k+ lines of complex syntax Salt systems only to break things, misconfigure them, and leave the system totally dependent on the author (aka the genius). We have ran systems of 100+ machines with a few lines of bash - so I am blown away at this new complexity. PLEASE help me out.

Re: Moving away from Puppet: SaltStack or Ansible?

#138
Two things:

> The DevOps team felt that the Puppet infrastructure was too difficult to pick up quickly

Uh. I hate to break it to you, but rewriting your infrastructure from scratch isn't quick either.

> Code should be as simple as possible. Configuration management abstractions generally lead to complicated, convoluted and difficult to understand code.

All code becomes complex over time if you do something different with it. Refine your abstractions instead of throwing out code. Or use more composable components instead of writing new code.

Finally i'd add that before you throw out a thing, your main concern should be "is there something we cannot do with the existing thing?" There will always be a better wheel, but if your existing wheel works, you should probably stick with it.

Re: Moving away from Puppet: SaltStack or Ansible?

#139
It would have been interesting to see them add Puppet to the list of tools to evaluate (while doing their best to do so objectively as 'new users'). It seemed to me like most of the issues they'd encountered were self-inflicted, rather than the result of using Puppet specifically?

Re: Moving away from Puppet: SaltStack or Ansible?

#140

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…

You actually answered your own question.

>I have seen guys try these 9k+ lines of complex syntax Salt systems only to break things, misconfigure them, and leave the system totally dependent on the author (aka the genius).

A lot of it is job security, even if that job doesn't pay them anything.

Post reply on HN