[HN Gopher] CINC Is Not Chef
___________________________________________________________________
CINC Is Not Chef
Author : duck
Score : 50 points
Date : 2025-04-04 17:22 UTC (5 hours ago)
(HTM) web link (cinc.sh)
(TXT) w3m dump (cinc.sh)
| klooney wrote:
| Are there Chef Habitat users in the wild?
| lgeorget wrote:
| Are we talking about the orchestration software, like Ansible
| and Puppet, or is it something else?
| holysoles wrote:
| Its 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/ [2]
| https://cinc.sh/blog/cinc_client_is_live/
| nunez wrote:
| I was never really able to grok this tool. It always felt like
| Docker with extra steps.
| arm32 wrote:
| I'm dumb and can't figure out wtf this is.
| bognition wrote:
| Chef is an infrastructure as code configuration system. The
| binaries are now proprietary. This is a FOSS replacement.
| 0cf8612b2e1e wrote:
| Huh. Given Ruby/Chef lost, are the Chef maintainers going for
| a final financial squeeze of whoever is still on the
| platform?
| slipheen wrote:
| I think the license change and initial fork was back in
| 2019? It's been a while.
| aranchelk wrote:
| Did anyone ever tell them they lost? Are you volunteering?
| slipheen wrote:
| A few years ago, Chef (configuration software, sort of like
| ansible) changed their license, and this is a fork which
| maintains the open source.
| bigstrat2003 wrote:
| 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).
| jonathaneunice wrote:
| 2013 called and wants its favorite infrastructure as code (IaC)
| tool back.
| bigstrat2003 wrote:
| 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.
| eltondegeneres wrote:
| IMO Ansible is easier to get started with, but less powerful
| than Chef.
| yjftsjthsd-h wrote:
| 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.
| bigstrat2003 wrote:
| 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.
| hnlmorg wrote:
| 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.
| esseph wrote:
| https://docs.ansible.com/ansible/latest/cli/ansible-
| pull.htm...
| doubled112 wrote:
| 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.
| closeparen wrote:
| To me a deployment of new code or config is a workflow.
| The ordering and timing of its progress of the fleet is
| very important. You want to be able to plan it, watch it,
| and pause or reverse it from that perspective.
|
| SSH is inadequate because this process should be _much_
| slower than the life of anyone 's terminal window. You
| could approximate it with cronjob pulls if each node's
| schedule is a little offset from the previous. But you
| probably also want different rollout schedules available
| for different scenarios.
| TheCraiggers wrote:
| 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.
| escape_velocity wrote:
| 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.
| eltondegeneres wrote:
| You could use Chef in local mode and pull down the
| cookbooks from s3 or something.
| sofixa wrote:
| > 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
| curun1r wrote:
| All three of those tools immediately felt, to me, like the
| wrong approach the moment I first experienced Docker. The
| notion that production infrastructure should be mutable and
| we use automation to make changes to it just introduces so
| much more state than is necessary. Immutable infrastructure
| eliminates so many sources issues.
|
| And I think that's where the comment you're responding to is
| coming from. Once you've experienced Docker/K8s and, to a
| lesser extent, IaC tools like Terraform, it's hard to see
| yourself ever going back to tools like Chef in the same way
| that tools like Chef made it hard to see going back to a
| world where we configured servers manually.
| bigstrat2003 wrote:
| Docker, k8s, Terraform etc are nice. I make extensive use
| of them too. But in my opinion they can't be used for
| everything, because mutable infrastructure is a reality of
| the world that must be accounted for at some point. For
| example, at my employer we have on-prem k3s clusters
| running on bare metal servers. Chef is a perfect tool to
| manage those, because they are by their nature not
| something we can treat as stateless, immutable
| configurations.
|
| It seems to me that this is kind of like abstraction levels
| in programming. If you can use a high level language with
| lots of powerful tools, you do. But some people have to
| live in the world of C or even assembly, because (as James
| Mickens said) you can't just place a Lisp book on top of an
| x86 chip and hope it learns about lambda calculus by
| osmosis. I view IaC tools in the same way: if you can use
| Terraform or Docker, great! But someone has to use lower
| level tools to provide the environment in which those
| things exist. And that's why people shouldn't look at Chef
| (or other similar tools) as outdated, any more than
| assembly is outdated just because Lisp exists. They still
| very much have a strong use case that won't ever go away.
| dsr_ wrote:
| UNIX: 1973
|
| vi: 1976
|
| BSD UNIX: 1978
|
| x86 instruction set: 1978
|
| UNIX System V R4.2 1983
|
| Linux: 1991.
|
| Kids these days.
| nunez wrote:
| Chef is still popular in the enterprise. It's a good tool.
| jonathaneunice wrote:
| It's an okayish tool.
|
| After using it for a few years, accumulated enough quirks to
| significantly diminish my initial enthusiasm. The concurrency
| gotchas, the utter lack of debugging and profiling tools, the
| weak management of today's most common deployment models
| (e.g. Docker/containers and cloud services)...it's not "good"
| by 2025 standards.
|
| I'm sure enterprises still do use it. But they also still use
| RPG, PL/I, and IMS. So...
| kureikain wrote:
| 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.
| geerlingguy wrote:
| 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.
| aae42 wrote:
| It's an interesting post. I feel like people who are still doing
| Chef definitely know about cinc already.
| tekla wrote:
| 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?
| hkt wrote:
| Ansible? Fabric? Cloud init?
|
| Fabric is a favourite for this kind of thing (although I'm
| configuring VMs at runtime instead of building AMIs)
| inopinatus wrote:
| I went back to shell scripts.
| geerlingguy wrote:
| For 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 wrote:
| They're all good and bad in different ways. You just need to
| pick one. Ansible is GPL3, opentofu is Mozilla Public License.
| bigstrat2003 wrote:
| For 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.
| cassianoleal wrote:
| For immutable infra, shell scripts are king. You're essentially
| just installing packages and copying files around, there's
| really no need to get any more complicated than that.
| don-code wrote:
| 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.
| nunez wrote:
| Right. 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 wrote:
| While 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 wrote:
| I 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).
| ghshephard wrote:
| I 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 wrote:
| Terraform 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.
| a3w wrote:
| What is Chef? This website fails to answer that.
| jjasghar wrote:
| To 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.
| echohack5 wrote:
| Man 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 wrote:
| I misguidedly thought this was going to be about Chef in
| Apocalypse Now. Don't get off the boat!
___________________________________________________________________
(page generated 2025-04-04 23:02 UTC)