6 ms·
CINC Is Not Chef
- arm32 2y agoI'm dumb and can't figure out wtf this is.
- bognition 2y agoChef is an infrastructure as code configuration system. The binaries are now proprietary. This is a FOSS replacement.
- 0cf8612b2e1e 2y agoHuh. Given Ruby/Chef lost, are the Chef maintainers going for a final financial squeeze of whoever is still on the platform?
- jtimberman 2y agoThe Chef-branded distribution is still built from the same open source repositories that the CINC project is built from; it isn't proprietary. It has an additional EULA that requires people to accept and thus [presumably] pay for. It's basically the same model as Red Hat. Except Chef never had the market penetration and brand recognition as a trusted source that Red Hat has. Signed, someone who worked for Chef for almost 13 years.
- slipheen 2y agoA few years ago, Chef (configuration software, sort of like ansible) changed their license, and this is a fork which maintains the open source.
- bigstrat2003 2y agoMany 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).
- klooney 2y agoAre there Chef Habitat users in the wild?
- lgeorget 2y agoAre we talking about the orchestration software, like Ansible and Puppet, or is it something else?
- holysoles 2y agoIts a variant of the orchestration software. I'm not sure this is as enticing as other permissive licensed projects like OpenTofu/Ansible (push) or OpenVox (pull) based on available documentation/market share. Of note, this is not affiliated with Chef itself [1], but looks like Chef has blessed it [2] [1] https://cinc.sh/disclaimers/ https://cinc.sh/disclaimers/ [2] https://cinc.sh/blog/cinc_client_is_live/ https://cinc.sh/blog/cinc_client_is_live/
- nunez 2y agoI was never really able to grok this tool. It always felt like Docker with extra steps.
- jonathaneunice 2y ago2013 called and wants its favorite infrastructure as code (IaC) tool back.
- bigstrat2003 2y agoTools 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.
- eltondegeneres 2y agoIMO Ansible is easier to get started with, but less powerful than Chef.
- yjftsjthsd-h 2y agoI 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.
- bigstrat2003 2y agoThe 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.
- hnlmorg 2y agoAnsible 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.
- esseph 2y agohttps://docs.ansible.com/ansible/latest/cli/ansible-pull.html https://docs.ansible.com/ansible/latest/cli/ansible-pull.htm...
- kureikain 2y agoIf 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.
- geerlingguy 2y agoIt 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.
- aae42 2y agoIt's an interesting post. I feel like people who are still doing Chef definitely know about cinc already.
- tekla 2y agoI 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?
- hkt 2y agoAnsible? Fabric? Cloud init? Fabric is a favourite for this kind of thing (although I'm configuring VMs at runtime instead of building AMIs)
- inopinatus 2y agoI went back to shell scripts.
- geerlingguy 2y agoFor me, Ansible and Pyinfra, but I've been leaning on shell scripts for very simple things that I know will be mostly the same for 5-10+ years, and sometimes I wrap those into larger playbooks.
- jacobsenscott 2y agoThey're all good and bad in different ways. You just need to pick one. Ansible is GPL3, opentofu is Mozilla Public License.
- bigstrat2003 2y agoFor creating AMIs? Probably Ansible or something similar. Chef is great for ongoing management of servers, but not so good for a one-shot config run like you would do if you're creating AMIs.
- aae42 2y agoI still use it for that. Built a really nice packer based process that pulls in Chef cookbooks and applies them in zero mode. Even have an integration test of the resulting AMI in later stages using test kitchen (Chef's "killer app" imo) with the EC2 driver to spin up an instance with the AMI and run Inspec tests on it.
- don-code 2y agoChef 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.
- nunez 2y agoRight. If Chef had adopted agentless earlier (or, rather, made Chef Solo less confusing to use), Ansible would not have eaten its lunch like it did.
- nyrikki 2y agoWhile I agree with a lot of what you said. In my experience, it was the need for orchestration that killed it but we are probably using different definitions of "immutable", where in Chef context I think of it as the infrastructure. For me the killer feature of ansible for me was the ability to gate based on remote state, which really was incompatible with the foundational engineering choices that were almost ideal for its original target. When you were upgrading rabbitmq, postgres, etc... the view from other cluster nodes was critical, not the local view. Both chef and puppets tried to graft on what they called orchestration, but was really just batch jobs. Immutable infrastructure was fairly easy IMHO with chef if your architectural quantum was a machine, but not for situations where that quantum was a cluster, especially with data that needed to persist like with Cassandra etc...
- acidmath 2y agoI haven't encountered any Chef code in almost ten years. For the stragglers not yet primarily on Kubernetes and Terraform, I see Ansible and some extra Terraform. Maybe I see some Salt here and there. These are just my anecdotes, for sure, but (also anecdotal) I rarely hear of other "ops" type people using Chef, and most of the ones I know never got more than just their feet wet with Chef (the SaltStack beta was out early enough to avoid Chef).
- deleted 2y ago[deleted]
- ghshephard 2y agoI think you would be quite shocked to discover how many millions (10s of millions?) of nodes at hyperscalers and adjuncts are configured with Chef. > For the stragglers not yet primarily on Kubernetes and Terraform In my experience - you see all three of these, k8s, TF and chef working in the same cluster. But, I'm only an anecdote of n=2.
- bigstrat2003 2y agoTerraform and Chef definitely go well together. Like peanut butter and chocolate. Terraform is great at provisioning cloud resources but not so great at configuring the details once they're up, Chef is great at configuring servers that exist but can't do squat to provision them in the first place. At my job we use both of them quite a bit to manage our stateful EC2 instances, because of the way they complement each other.
- snovymgodym 2y agoI committed some Chef code into production today, at a FAANG no less. It's not great, but it works I guess. I do wish we were on SaltStack or Ansible instead.
- aae42 2y agothis is interesting to me, i know Facebook still uses Chef, are there any other FAANGs that do?
- a3w 2y agoWhat is Chef? This website fails to answer that.
- jjasghar 2y agoTo quote the first line of the website: > A Free-as-in-Beer distribution of the open source software of Chef Software Inc. See goals for details, or follow our blog for updates on the project.
- a3w 2y agoYes, I clicked details. It told me, again, that this is a chef distribution. What is chef, I asked after reading the details page, again. (Only then did I originally post my question to Hackernews. I can read. The info just is not there.)
- echohack5 2y agoMan I miss Chef. It was wildly good for its time with a vibrant community. Habitat was cool but tried to carve into some niches that were too ambitious. And InSpec was an incredible tool but failed to build the critical community to drive it forward. I haven't experienced anything like the Chef Community since. (AI has some of these vibes in small pockets but it's very disjointed) Now we're stuck with what I call the "DevOps ball of mud". I gotta learn 15 different yaml formats alongside the nuances of every hyperscaler and micro cloud. Like seriously it's 2025 and we still gotta deal with stateful bullshit and a bunch of unoptimized docker containers flung all over the place. It feels like nobody has solved the application runtime stateful egg and we're all just dancing to the dark gods of Docker, Kubernetes, and Helm in hopes that our blood sacrifices make the engines go for another month. Full Disclosure: I worked at Chef for 5 years
- zabzonk 2y agoI misguidedly thought this was going to be about Chef in Apocalypse Now. Don't get off the boat!
- fewuhfweif 2y ago[dead]