Historically there were 4 main configuration management tools: puppet/chef/ansible/salt.
The first two faded away. They're unarguably not the most usable and require to program in ruby. The next generation ansible/salt came out and arguably did better on every aspect.
I think it's fair to say that ansible is the safe standard (redhat acquired it few years ago, they maintained and extended it pretty well). Ansible is very easy to use and to integrate in anything as long as you have SSH access.
The only downside of ansible is that it can get slow with thousands of hosts to manage (gotta establish SSH connections). Salt can do better with large amount of hosts.
I don't want to orchestrate against hundreds of systems with SSH and tell them what to do. I'd rather tell them what I want, and let them sort it out locally.
Pass all of your variables and dependencies (role artifact urls, python requirements.txt, etc) to machines through user data and have the machine download the dependencies and run ansible-playbook to configure itself. Optionally, add a systemd timer to run it on a schedule and you have an "agent".
I've done it this way a large percentage of the time using ansible. The other way is by baking images and using ansible as the provisioner (using ssh but only during the image build).
That has been my experience/perspective as well. This was what I found industry...
* ~2012 Puppet golden years * ~2014 Chef golden years * ~2016 Surge of popularity for Ansible and Salt. * ~2018+ Kubernetes ubiquity, Terraform for cloud, Ansible for systems
Related to this, saw popularity in SSR (server-side rendering) with Rails before 2012-2016, and after 2016 rise of popularity in SPA (Angular, React, Vue) on top of micro-frameworks like Flask (Python), Express (Node), GoLang, others. Combined with this are ML and other backend infra that requires managing clusters that scale better on Kubernetes, where Chef/Puppet have little presence on either K8S or backend distributed clusters.
https://www.cvedetails.com/vulnerability-list/vendor_id-1294...
Thanks a lot for building this!
I toyed with a simple puppet-alike, written in golang, called marionette (in hindsight a terrible name):
https://github.com/skx/marionette/
It isn't anywhere near as complex, or featureful, but starting with golden AMIs it allows the necessary changes that I need in a consistent fashion.
Well, yeah, especially as Puppet has a well known solution named Marionette Collective
* https://puppet.com/docs/mcollective/current/index.html * https://choria.io/docs/about/mcollective/
You're proposing that he replaces a cross platform tool with an entire OS and on top of that with a tool that has a very peculiar package management system (I'm not saying it's bad, just that it kind of requires full buy-in to make it work).
When doing immutable infra, where managing desired state is only at deploy time, then Ansible is by far more popular. Beyond that you get into container scheduling-orchestration platforms.
Others mentioned Terraform and Pulumi, which manage cloud resources, where Chef manages mostly system resources. Once upon a time, there was an attempt with Chef Metal, and later rebranded as Chef Provisioning, which are drive by chef-solo (or chef-zero) and use fog driver. The end result was something that was so gawd awful terribad, unstable, and unpopular. Instead of Chef investing to improve it, Chef started promoting Hashicorp Terraform over their solution.
CINC is the recent-ish community build of the code. It's literally a drop-in replacement as the only changes to Chef Client and other bits are branding. It's the CentOS to Chef's RHEL.