The first release of OpenVox, the OSS implementation of Puppet

Companies with 100s to 1000s of hours of investment in software like Puppet aren't going to rearchitect without being forced to. By the application becoming unsuitable for current needs, or due to cost.

Broadcom bought out VMWare and jacked the price up by unworkable amounts. Puppet is now owned by a venture capital company and the non-zero possibility is they'll follow Broadcom's playbook. That's why Puppet is being forked.

Why not contribute to Ansible or Salt? What individual programmers do in their spare time is irrelevant to the majority of users of those products.

"There are 2 hard problems in computer science: cache invalidation, naming things, and off-by-1 errors."

The names of things today is terrible. If I hadn't known what Puppet was, even vaguely, I would have thought this was some kind of speech recognition or TTS project as well. This may as well be called "FileDefrag" or "OpenSec".

Puppet and Ansible (not sure about Salt) works very differently. Puppet is pull based, as in each client pulls their configuration from a central server at regular intervals, where as Ansible pushes a configuration when asked. Puppet is also more of a "Ensure that my client is in this state" while Ansible can be see as "Run these steps on the client", that's not a 100% accurate and people have also made Ansible work in a pull configuration, but I feel that makes picking one over the other a little simpler.

In any case, Puppet is easier to scale to thousands of servers. Ansible is easier to develop for and easier to upgrade or run multiple versions simultaneously. It two different approaches to the same/similar problem, but they are fare from interchangeable.

There are other ways to use the tool, however. In contrast with a centralized infrastructure, it's also possible to just collect a few puppet manifests in git, then you simply clone the repo and run `puppet apply` on demand.

Puppet is still a powerful language for declarative representation of system configuration. Works to apply a specific configuration at a specific time or as a way to automate the construction of VM images.

One place puppet excels is when you want to reuse a bit of configuration in bare metal, virtual machine or container images. With puppet you can pretty easily generate all three from one source of truth with minimal special-cases for the config variants.

All that being said, I haven't reached for puppet as my first choice tool in quite some time. Maybe time to change that and give OpenVox a look. It'll be a win if OpenVox saves me from further suffering through the indignity of working with Ansible.

Reminds me of the (bad) plot element from Star Trek: Picard where Picard's son became "Vox" and was able to control people on behalf of the Borg.

Puppet or Puppeteer ?

Ansible is a little bit easier to get started for a few reason (yaml instead of a DSL, ssh only...) ; it's also mostly tasks running through SSH which may feel a bit more "natural" when you are configuring machines initially.

In terms of idempotency I find it is easier in ansible to mess up something but if you are careful they are on par. I've used mostly ansible over the past few years in various jobs but the first I got in touch with ~10 years ago was puppet and it felt very solid especially for heterogeneous environments (we had different archs and OSes to manage). Also puppet scales very well because it has agents as well as many tools to manage large infrastructures which I tried and were already quite convenient 10 years ago.

TL;DR probably use ansible unless you have a very specific use case.

If you have other systems to manage, like Windows or VMware ESX etc., it feels like a kludge with the delegation to localhost to get to the plugins.

Also, it can be tricky to use if your Linux systems have different Python interpreter versions because it's not at all straightforward to override the python interpreter used.

Looping constructs and sub-tasks etc. are also awkward to use, and the initial setup for a small automation project might be overwhelming for newcomers.

On the other hand you get a massive community with plugins for almost every conceivable system/OS, so that's definitely a huge plus

Puppet always seemed to me like a scalable enterprise solution, but you either need a team to keep it in check, or just never update.

I'm not specifically recommending Ansible, but it's what I've been using for a couple years, and I would always recommend that for home use over Puppet.

Disclaimer: I last used Puppet in 2017, but for like 7 years extensively before that and everything I mentioned happened several times.

Second disclaimer: By now I think parametrizing everything is a huge mistake - the real worth is editing the config in one place and having it in SCM. if you only parametrize 2 lines out of a 100 line config file and basically copy it over with 2x `sed` - that's fine.

And never commit inline secrets. Find out one of the ways to inject/separate/template secrets that's workable for you to stick with it.

Ansible will allow you to do that with just "pip install ansible". Puppet requires you to setup so infrastructure, which you need to way of bootstrapping.

Personally I also find Ansible easier to work with, in the sense that you can more easily do stuff in small increments. Upgrading Ansible is also a lot simpler. Puppet really cool and powerful, but for home stuff or a small business I'm not sure the overhead of managing Puppet itself is worth it.

My favorite part of puppet is demonstrated well by the trifects:

   package { 'openssh-server':
     ensure => installed,
   }
   
   file { '/etc/ssh/sshd_config':
     source  => 'puppet:///modules/sshd/sshd_config',
     owner   => 'root',
     group   => 'root',
     mode    => '0640',
     notify  => Service['sshd'], # sshd restarts whenever you edit this file.
     require => Package['openssh-server'],
   }
   
   service { 'sshd':
     ensure => running,
     enable => true,
   }

Not a fan of ansible, it's more of a "run this playbook", which translates to reinstall and "run this playbook", which in environments that don't reinstall very often can be painful. Since ansible playbooks don't know the current machines state they never know exactly what commands to run.

Generally if you spin up containers or similar short term servers I think ansible is fine. If it's a larger and more complicated environment with longer lived servers I'd use puppet.

Oh, one other think I like about puppet is if you say apply X to all nodes, you can literally not run puppet (it will fail to compile the manifests) if you try to override it. Which security auditors LOVE.

https://pyinfra.com/