I use CFEngine to manage tens of thousands of Linux hosts. I've used their enterprise edition with their agent, which is really outstanding. I've also run it at the same scale agentless, using their community edition. I have used it for one-time configuration at system installation, and have run it every 5 minutes on every host in our plant. The speed of execution and the clarity of the language are second to none, and when I was using their enterprise edition, I found their support and engineering services to be top-notch. I've been using it for 15 years or so, across several companies. While other configuration management systems get the job done, I haven't used any as straightforward and scalable as CFEngine. Many thanks, Mark Burgess!
This was a good read for the fundamentals, it's nicely opinionated and would get a lab of unix workstations running even today (if allowed substitutes like cvs->git.)
But what do you do if you have ~0 unix workstations? Mobile clients, BYOD, offsite IaaS/PaaS, PKI certs for an https-only world, 3rd party APIs, file share between windows/mac clients all make things more complex. Do you want your infra to retrieve packages over port 80 until you can setup the CA to get trusted 443? Do you want to keep API keys in git until you can setup the vault-server? Are there any services you should NEVER authenticate through Okta?
Would be neat to see a modern bootstrap walkthrough from "founders use gmail and a Wix.com site" to a zero-trust(ish) set of company-hosted services that 100 remote/on-prem employees can access with a single credential set from devices including company workstations and personal laptops.
I tried CFEngine3 for some personal configuration management needs a few years ago, and I was impressed by how well thought out and designed it seemed compared to the more popular alternatives.
Ultimately I ported over to Ansible because that's what I need to maintain fluency in for professional reasons, but I really lament it. It's a slog through mud compared to the clarity that is CFEngine.
When I was looking for a configuration management system, I too was impressed by cfengines theoretical underpinnings. however I also went with ansible. mainly because the cfengine story was "commit your entire configuration world immediately to cfengine" and ansible's was "you don't need to commit to anything, we will ease you into it. first, here is how you run a command remotely...." Not needing an agent really won me over.
First time I heard about CFEngine in ~2004. Version of that time didn't impress me. However CFEngine3 is a totally different story. I have been using it since 2012 and have not plans to switch. Even though CFEngine is not the most popular one it's one of the subjectively 'best'. Agent-less or kind-of-agent-less options like Ansible are not good enough feature-wise. Chef and Puppet are less convenient to me because of dependency on ruby.
Salt is unfortunately (in my two year old experience) full of features and strange bugs related to them - I do remember encountering a bunch of memory leaks master side for example. Deployment had the classic issues of python applications.
The core was (mostly) solid, but if you need anything done on it do buy the time of some consultant working on it already.
It's not as accessible as ansible, but definitely more accessible than cfengine. At least coming from Ansible.
I used Salt ~5 years ago, so things may have changed, but I wasn't impressed. In theory, it is an immensely powerful system. The broadcast system offers ways to orchestrate things in a way that's hard with eg Ansible.
The reality was that it was unstable, and use cases that needed the broadcast system were rare and often contrived. Agents crashed or hung constantly. We ended up mostly using the same features Ansible already had.
I might PoC it if I was going to deploy at a scale large enough where Ansible being centralized was an issue (i.e. there are so many hosts that it takes hours for Ansible to run). I'd have to see whether the pain of managing agents was better or worse than trying to shard Ansible. My suspicion is that it isn't too hard to shard Ansible deployments, but I could well be wrong, I haven't tried.
I used it and even took a class taught by salt stack employees.
I really was not a fan. I think one of the core problems I ran into was that the tool attempted to layer on rpc behavior to what was fundamentally a broadcast.
So you'd apply something to everything with a web role. The tool would attempt to make it appear as if you executed apply on n nodes and return after n responses. But since this was all just a broadcast what really happened is the tool dropped a message on the bus and then guessed how many responses it would get. If it guessed wrong the cli invocation would just hang.
I stumbled on this after realising that Mark Burgess, who created CFEngine, is also the author of this other recent HN post on "Using Promise Theory to solve the distributed consensus problem" [0] (from the same blog).
I don't know why Annatar's alternative viewpoint on packaging was down voted so aggressively, especially when so many non-CFEngine automation posts were allowed.
In my workplace, spending some time packaging our app using FPM made our Ansible playbooks a lot simpler. Config management and packaging work great together.
