Automation and my love/hate for Puppet

Community
1

Hi

This might be completely of topic but have to vent some frustration:

With the end of Centos 7 next, year I have been looking at moving my Asterisk PBX software to Rocky Linux while also trying to keep on trend with the new automation software like Puppet, Ansible and so forth. I decided to look at using a Puppet Master with client VM and on site servers as agent.
So I had to start learning to code puppet manifests and modules and things were going well.

My current Asterisk PBX software is currently installing all the packages and compiling the Asterisk software from a kickstart file. So should be simple enough, replicate what the kickstart is doing in a Puppet module.

  1. Install the packages required. Done with Puppet
  2. Install group packages. Done with Puppet forge yum module
  3. Change selinux - Done with Puppet forge selinux module
  4. Sync file from Master server (Multiple files so let look at rsync)
    • This is were my first issue came up. I was oky, let use the Puppet rsync forge module and I just could not get it working. So I looked at the Puppet rsync module source code and found that basically it’s going a Puppet Exec and running a rsync command. Now I am already like but I can do this using a rsync deamon on the master
  5. Scrapped the Puppet rsync module and created my own module to just run a rsync exec command. Next problem, I need to enter a password or use SSH key. So SSH key created and it’s copied from the Puppet master using Puppet file resource.
  6. Compile the Asterisk PBX software using a bash script. Again using the Puppet exec command but i don’t want the bash script to execute every time puppet agent run, so we create a lock file to check if it exist and then execute won’t run.

Basically we are done. Puppet does what my kickstart is doing. However now I need a kickstart to install the Puppet agent and setup it’s config file. Again I ask why did I even bother with Puppet

  1. So the kickstart file is created. I install the Puppet agent and I create a config file

So at the end of the day. I went through all of this just to back using a kickstart file. So I was like, did I just do all of this for nothing. I could just as well have stayed with my original kickstart file and bash scripts that monitors for file changes and new packages.
I then realized maybe not all cloud platforms support VM installing using a kickstart file, since I have always really only worked with KVM. My company is currently using Hyper-V and kickstart files works. I then asked a Azure friend and if I understand him correctly I can’t specify kickstart for an azure VM.

So maybe at the end of the day it might have been a good thing.

2

For comparison, Ansible is not fond of copying a tree of files either.

In grid computing or “IO nodes” of HPC cluster (local SSD in them) an “optimization” is to copy one tarball to destination and extract it there. That probably lacks the “are we there yet?” idempotency that Puppet/Ansible are nice about.

Ansible has no agents/daemons. The process in controlhost connects (ssh) to managed hosts and executes (python) in them. Hence only one host needs the Ansible packages.

I’ve used libvirt/KVM, opennebula, and openstack. On the first PXE boot of the installer with optional kickstart – usually just “Minimal install” packages and drop in ssh key for Ansible to connect and do the rest.

Openstack had images – I could upload Rocky cloud image there – and some initial config via cloud-init. After that Ansible again. (IIRC, nebula was similar.)

IIRC, when Red Hat made the announcement, they did mention that Facebook was already making use of CentOS Stream (as it was back then) with Puppet. Hence Puppet ought to have what it takes (or FB has secret magic of their own).

3

Thanks.
Let me ask this, why even need any of automation if a bash script and cron can do almost all of this as well?
I will do some more reading and ask GhatGPT as well.

4

is automation too. For example, the Ansible is “just” a Python script.

A difference is that somebody else, (smarter?), wrote the Ansible/Puppet scripts and maintains them too; we only have to supply appropriate variables. With scripts that we write ourself, every bug is our own doing.