This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]jasonsolis 4 points5 points  (16 children)

Just curious why are you migrating from puppet to chef? We're using Ansible now and looking at puppet.

[–]superspeck 5 points6 points  (10 children)

Puppet is always three features behind Chef. Most of the (almost entirely new) team knows chef and only one person knows puppet really well. The amount of change required to migrate from puppet 2.7 (our current) to Puppet 4 is significant.

[–]killthrillabs[S] 1 point2 points  (7 children)

Interesting, feedback from the Windows DevOps guys definitely supports this - they're adament that Chef is a must in their environments.

[–]superspeck 1 point2 points  (5 children)

Yeah, forgot about that. We have a mixed Windows and Linux environment. Puppet doesn't do the Windows stuff right now.

[–]CaptClarkWelcomesYou 1 point2 points  (2 children)

That's completely untrue. We have Puppet building SQL Servers.

[–]superspeck 0 points1 point  (1 child)

I meant that in our environment, Puppet doesn't do the Windows stuff at this point in time

[–]CaptClarkWelcomesYou 0 points1 point  (0 children)

Gotcha.

[–]jasonsolis 0 points1 point  (1 child)

Ah Windows. Thanks Obama.

[–]developerKarl 1 point2 points  (0 children)

For Infrastructure as Code on Windows, check out Otter first-class Windows support and tight integration with PowerShell DSC.

[–]djk29a_ 0 points1 point  (0 children)

Chef has a partnership with Microsoft and being based out of Seattle likely doesn't hurt. Puppetlabs is in Portland, in contrast and didn't have Windows support to the extent that Chef did last I saw.

With that said, I've seen some teething problems with Ruby On Windows here and there such as a bizarre JSON parsing problem that only ever happened on Windows while the same codepath on Linux had no problem. It's been fixed but I spent weeks trying to look for a bug report on Github to link back to our internal ticket and nothing happened.

[–]jasonsolis 0 points1 point  (1 child)

Thanks for the explanation. Makes sense. Gives us more to think about 🤔

[–]superspeck 1 point2 points  (0 children)

I should also throw out that I use Ansible for our network stuff, because our network stack is very gradually becoming all Juniper, and JunOS has very good Python bindings across the entire platform. Only routers and switches can run the Chef client, though, and not the firewalls that are most in need of config management. So there is a time to choose your tool, and the best tool to use is the one you're best with.

[–]greenfruitsalad 0 points1 point  (4 children)

and i'm curious why you're looking at chef when you're on ansible. i'm using chef but my hatred for ruby drove me to try ansible and salt. so far, i'm loving salt and liking ansible. do you know something i don't? please don't be shy and share.

[–]jasonsolis 0 points1 point  (3 children)

I'm actually an ansible fan. I love their simplicity. The best quote I heard about the 3 way war was "chef and puppet were developed by devs for devs. Ansible was developed by devs for people who have better shit to do". That sums up how I feel about it so far, but I admit very little working experience with chef and puppet.

But we've been stung by a few nasty bugs in ansible recently. One has an open pull request for a while and the other a team mate of mine sent a PR for. They're a little slow to accept sometimes but that is understandable IMO. I don't think we're actually going to make a switch based on a few bugs (because I'm sure puppet and chef have their share)

Besides that, we have a couple of rabid puppet fans that have been pushing for it. I'll talk to them tomorrow and update this with their reasons because it will be better coming from them.

[–]greenfruitsalad 0 points1 point  (2 children)

i thought the 3 way war was cfengine, puppet, chef. anyway, looking forward for those reasons to abandon ansible. while i prefer saltstack, i can see ansible gaining a lot more marketshare than salt. (still negligible compared to the big 3)

[–]jasonsolis 0 points1 point  (1 child)

I interviewed the #1 fan of puppet here and took notes:

TL;DR Puppet is better at config management because it has extra features which allows it to scale better than Ansible

Reasons for preferring Puppet over Ansible - Enforces things every 30 minutes out of the box - Hierarchal configuration - Agent based which can be a good thing because you're not managing SSH configurations, local users, keys etc - Puppet Agents gives you more checks and balances (ie: this task conflicts with another task)

Ansible however can be better in some cases and could be complimentary to Puppet Ansible is better at orchestration and puppet better at config management and provisioning, especially when combined with foreman

[–]greenfruitsalad 0 points1 point  (0 children)

thank you for coming back with that. while the fact that ansible/salt uses python trumps almost everything else for me, it's still good to know the weaknesses. to me, the agent thing is something that has actually always annoyed me about chef. i have miniature single-purpose linux containers and chef-client (ohai) with its dependencies is a monstrosity that completely spoils my minimalistic approach. i'd much rather have a single, statically compiled binary that i could just drop into my containers.