Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

CINC Is Not Chef

cinc.sh

Post reply on HN
Print view View original

21–30 of 57 posts

Re: CINC Is Not Chef

#21

Post by hnlmorg »

bigstrat2003 wrote: post #16
yjftsjthsd-h wrote: post #14

Earlier quoted context omitted.

I liked writing chef, but the client/server model and its knock on effects (IIRC, needing to upload changes with knife?) was annoying. Ansible is more painful to write but a delight to run.

The client/server model is why I like Chef more than Ansible, tbh. Having my machines run a service which pulls configuration on a schedule is, to me, much saner and easier to manage than having to push configuration from a central source over ssh. But that is obviously just my preference, and if someone doesn't like the client/server model then I can totally understand if they don't like Chef as a result.

Ansible can work that way too.

In fact every time I’ve migrated to Ansible (each time from Puppet), we’ve built the infrastructure so Ansible pulled its configuration.

Re: CINC Is Not Chef

#22

Post by esseph »

bigstrat2003 wrote: post #16
yjftsjthsd-h wrote: post #14

Earlier quoted context omitted.

I liked writing chef, but the client/server model and its knock on effects (IIRC, needing to upload changes with knife?) was annoying. Ansible is more painful to write but a delight to run.

The client/server model is why I like Chef more than Ansible, tbh. Having my machines run a service which pulls configuration on a schedule is, to me, much saner and easier to manage than having to push configuration from a central source over ssh. But that is obviously just my preference, and if someone doesn't like the client/server model then I can totally understand if they don't like Chef as a result.

https://docs.ansible.com/ansible/latest/cli/ansible-pull.htm...

Re: CINC Is Not Chef

#24

Post by sofixa »

yjftsjthsd-h wrote: post #14
bigstrat2003 wrote: post #11

Earlier quoted context omitted.

Tools don't stop being useful just because they aren't trendy. I still use Chef, and I love it. I much prefer it to Ansible or Puppet.

I liked writing chef, but the client/server model and its knock on effects (IIRC, needing to upload changes with knife?) was annoying. Ansible is more painful to write but a delight to run.

> the client/server model and its knock on effects (IIRC, needing to upload changes with knife?) was annoying

It also has tons of advantages, notably around scale (Ansible id very slow when working with thousands of machines) and ensuring that there is no drift. Also e.g. SaltStack (RIP) has cool features such as reactor to react to events on the machine which are only possible because there's an agent

Re: CINC Is Not Chef

#25

Post by tekla »

I legitimately have no idea what infrastructure provisioning tool to use anymore. I normally defaulted to Saltstack Masterless and Chef via Packer.

What "simple" tool is left anymore for me to create my immutable AMIs that aren't bound by some license?

Re: CINC Is Not Chef

#26

Post by hkt »

tekla wrote: post #25

I legitimately have no idea what infrastructure provisioning tool to use anymore. I normally defaulted to Saltstack Masterless and Chef via Packer. What "simple" tool is left anymore for me to create my immutable AMIs that aren't bound by some license?

Ansible? Fabric? Cloud init?

Fabric is a favourite for this kind of thing (although I'm configuring VMs at runtime instead of building AMIs)

Re: CINC Is Not Chef

#27

Post by inopinatus »

tekla wrote: post #25

I legitimately have no idea what infrastructure provisioning tool to use anymore. I normally defaulted to Saltstack Masterless and Chef via Packer. What "simple" tool is left anymore for me to create my immutable AMIs that aren't bound by some license?

I went back to shell scripts.

Re: CINC Is Not Chef

#28

Post by don-code »

Chef did not make a clean transition into the immutable world. Chef Client was great for persistent infrastructure, but the options got dicier once we started talking about pre-provisioned infrastructure like image building:

1. Chef Solo (how I last used it when attempting this), which felt intentionally hobbled. All you needed was one poorly-behaved cookbook that called `search` and the bets were off.

2. Chef Zero, which was unnecessarily complicated for being Chef Solo that wasn't intentionally hobbled, so much so that I kept using Solo for awhile after its deprecation.

3. Chef Client, against a Chef Server that was run either for your other persistent infrastructure, or just to have a place to put the cookbooks. Heaven forbid you weren't cleaning up all of those dynamically-created nodes, though...

I still think Chef's Ruby DSL is much more natural than the YAML manifests used by Ansible, and the ability to integrate at the source level with custom Ruby code is a killer feature as soon as any complexity enters the mix. But I almost certainly would not be using Chef in a greenfield deployment these days.

Re: CINC Is Not Chef

#29

Post by geerlingguy »

kureikain wrote: post #15

If you're still fighting with Chef slowness, hard to debug, complicated setup, you may want to consider Pyinfra. It is very well thoughout and simple to design and run.

It targets a different audience overall.

I've been using it a bit, and I like it. However, it is a lot more like programming in Python (rather than defining configuration) when you do anything outside the normal rails.

That's not a bad thing, but it is a different thing.

Still testing it more, and my needs are different than everyone else's, but so far I wouldn't say to anyone who already uses Chef, Ansible, Salt, etc. they could switch to Pyinfra, because the 'core' tool for automation is similar, but the ecosystem is altogether different.

I am moving some of my personal projects over to Pyinfra though, but for now mostly to flesh out my own understanding of it—my main stuff is all still Ansible.

Re: CINC Is Not Chef

#30

Post by doubled112 »

esseph wrote: post #22
bigstrat2003 wrote: post #16

Earlier quoted context omitted.

The client/server model is why I like Chef more than Ansible, tbh. Having my machines run a service which pulls configuration on a schedule is, to me, much saner and easier to manage than having to push configuration from a central source over ssh. But that is obviously just my preference, and if someone doesn't like the client/server model then I can totally understand if they don't like Chef as a result.

https://docs.ansible.com/ansible/latest/cli/ansible-pull.htm...

I use this to keep my (too many) Linux desktops configured.

A systemd service runs ansible-pull about 2 minutes after boot. It does its thing.

It has some annoyances, but it works fine. I don't think about it anymore. The git repo is the source of truth.

Post reply on HN