2013 called and wants its favorite infrastructure as code (IaC) tool back.
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.
CINC Is Not Chef
11–20 of 57 posts
Re: CINC Is Not Chef
#12I'm dumb and can't figure out wtf this is.
Many years ago now (2019ish), Chef stopped producing binaries for their software. The software itself remains FOSS, but you have to build it yourself. Cinc is a community project to build the software and distribute it (with Chef trademarks removed).
Re: CINC Is Not Chef
#13Re: CINC Is Not Chef
#142013 called and wants its favorite infrastructure as code (IaC) tool back.
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.
Re: CINC Is Not Chef
#15If 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.
Re: CINC Is Not Chef
#16Earlier 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 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.
Re: CINC Is Not Chef
#17Earlier 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.
Different use cases, probably.
I use Ansible personally when I'm dealing with a server or two. I use Puppet professionally when I am dealing with tens of thousands of servers and trying to keep them all in some kind of unity.
Re: CINC Is Not Chef
#182013 called and wants its favorite infrastructure as code (IaC) tool back.
UNIX: 1973
vi: 1976
BSD UNIX: 1978
x86 instruction set: 1978
UNIX System V R4.2 1983
Linux: 1991.
Kids these days.
Re: CINC Is Not Chef
#19Earlier 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.
You do indeed need to upload cookbook changes with knife; but if you keep your cookbooks in Git you can set up CI/CD pipelines that spawn a container that runs the knife upload steps for you (and even do validation via cookstyle before). Then all you need to do after changing your cookbooks and/or recipes is to commit those changes to your Git repo and watch the CI/CD pipeline do it's thing.
Re: CINC Is Not Chef
#20Earlier 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.
You could use Chef in local mode and pull down the cookbooks from s3 or something.