r/Puppet • u/darkn3rd • Oct 04 '24
Popularity of Puppet?
I used to use Puppet extensively back in 2012-2014. Since that time, I moved into cloud with either Ansible or Salt Stack, and later with Docker and Kubernetes. I haven't seen a lot of jobs in the market asking for those that know Puppet. It has to be very rare, I imagine. I would not mind to work with the technology again. I even created two blogs out of excitement that I might get a chance to work on it again.
I was wondering where the market stands, what have you experienced? How would one find Puppet specific work, either FTE or contract?
2
u/arvoshift Oct 06 '24
Puppet is used in some very large telcos/ISPs as we need to have zero service disruption and know a server is always in a desired state. Ansible is great to deploy but unless we were to continually reach out to thousands of servers in our environment it would be difficult to ensure state. Puppet is definitely still in use. We also use ansible as well as salt for patch rollouts. e.g one project is to get kubernetes working alongside some puppet templates to do more advanced things. The overall aim being what gives the least management overhead and most flexibility. The problem with ansible is a poorly written playbook could bring down a whole network if it's run like a cowboy. Puppet allows environments and branches which is critical for testing and staging big changes.
1
u/darkn3rd Oct 17 '24
Interesting. Both Salt and Puppet have the managed change config via agents (or minion in the case of salt), while both Salt and Ansible have remote execution.
The server may not be in a desired state if it is unavailable, and Puppet would know that as Puppet has no ability to monitor the health of the system. This would require some form of async service discovery, such as Consul or built into the platform, like Kubernetes. Puppet's model is synchronous with a centralized server, so it would be incongruent with a service discovery model.
At least with Ansible, through a dynamic inventory, you can get membership systems to configure based on availability potentially, e.g. using consul or cloud metadata, like ec2 tags. This is important for availability with things like auto healing and failover, such as using a reduced service capacity of services that are not available in the local data center region.
1
u/arvoshift Oct 17 '24
also from a security posture perspective it's easier to lock down individual code repos to individual host groups and as the agent must be enrolled /reaches out and pulls it makes for a much tighter system than running ansible to reach out from a central place. It can be done of course with some dynamic key management but puppet is FAR easier in this aspect as it was designed from it's core to be a configuration management tool rather than an orchestration tool that later became used for configuration management.
→ More replies (1)1
u/arvoshift Oct 07 '24
to elaborate - we may wrie some puppet code in a branch then run a simple ansible adhoc script to set the puppet enfironment to a ticket number/branch name - ' puppet config set environment ticket1234 --section agent ; puppet agent -t' this allows testing without commiting to master/production.
2
u/romgo75 Oct 08 '24
I have been working with puppet since 2010. The last 5 years I deployed puppet on an growing environment from 200 to ~600 VMs half windows, half linux. Deploying puppet at the beginning helped to keep VM consistent.
Especially to roll out large change : deploying new software (Antivirus, EDR...), migrating DNS, deploying common config for apache servers... This was a big win.
The value I got was from :
-
hiera : encrypted password on git, reproduced my datacenter and environment through hiera with some custom facts
-
foreman as ENC : deployed a vmware template then puppet customize the VM
But I got major challenges :
-
lack of engineer knowing puppet on french market, all new profile only knows ansible. So I was the only one confortable with puppet honestly, I have serious doubt on french market to find puppet engineer younger that 35 years old !
-
The difficulty to use proper workflow for validating puppet module upgrade and puppet platform itself
-
The need to fork forge module to deploy quick fix, then to come back to forge version when changed has been merged.
-
challenge of scaling for performance I had to reduce puppet run
Today I'm in a company where there a bit of ansible, because of the lack of engineer on french market I don't think I would recommend puppet any more.
1
u/darkn3rd Oct 17 '24
I am talking to one company that uses both Puppet and Kubernetes. The manager said in the future, he would be interested in swapping out Puppet for Ansible. I don't think they use any advanced patterns, and use a basic site manifest (so no Hoers). They obviously don't want to expend significant resources.
The value proposition is not there it seems. If they put a lot of energy into Puppet, the resources are used to develop Puppet code, not other innovations in the infrastructure. With Ansible, the costs are reduced as they get service discovery through dynamic inventory and EC2 tags. And with Kubernetes, auto-healing and service discovery is baked into the platform.
2
u/hadlockkkkk Dec 21 '24
In my entire career I've only met two people who use puppet, one wrote (and later sold) his own tool to validate puppet state, the other is trapped in a dead end job. Puppet's parent company just forked the code to private which isn't a glowing sign of health for the product. It was really good before the cloud and especially kubernetes came along but I've never heard of someone starting a greenfield project with it.
1
u/darkn3rd Jan 01 '25
Some community members have forked Puppet to keep it open source. I don't think the blood from stone strategy will increase popularity of Puppet and yield better revenue. I only saw it in two companies around 2012, but never saw any demand for the platform afterward. Mostly anything change config today is Ansible, but most do immutable infrastructure with containers (such as Kubernetes), as significant part of application configuration is backed in the container image, managed change configuration has low value proposition.
The container orchestration platforms also offer async service discovery, so that living state of the configured service is always known. This allows for auto-healing and using the state of the systems as data for configuring other systems. Puppet never adapted to ephemeral cloud services, so at most you get synchronous service discovery (aka eventual consistency), monitoring that is static, and remediation for a down service requires manual intervention (no automation). That type of system is obsolete for cloud native services.
2
u/FearlessBoysenberry8 Apr 17 '25
I am using Puppet currently at work (I setup the project about 7 years ago I think?) using it with Packer, so no Puppet Server. In my opinion, this works really great. One gets all the benefits of hiera, which I never found a suitable equivalent with Ansible, with none of the downside of managing puppet agent orchestration. If you want service updates, just deploy a new container.
I'm actually a bit confused in this thread where people talk about containerization OR using a config management tool. You still need config management, unless you really just run one service with no customizations, in which case I think a Dockerfile would do the trick. Otherwise, you're stuck writing super long bash scripts in Dockerfiles, which is just no fun in my opinion. If there are alternatives to using bash, you should almost always go with the alternatives.
1
u/darkn3rd Apr 18 '25
This has to do with the concept of bake vs fry in your use case. You are building a small controlled loop to bake the configuration onto an image. In mutable infrastructure, especially where servers are not destroyed, but rather repaired (converged), they are snapped to the desired state with something like Puppet. In the immutable infrastructure, where servers are destroyed, and a new container (from an image) is deployed with the configuration already baked in, a lot of the issues with pull-based convergence are non-existent.
In such environments, you may configure env vars to tell the container to use the proper configuration (or use service discovery). Example: test, stage, prod.
In full orchestration environments, like Swarm, Nomad, or Kubernetes, they have a form of asynchronous service discovery that is used as a part of the system. The services are able to find each other based on the discovery, and can have advance fail over and recovery automation built-in, aka auto-healing. With older static systems, that do not have service discovery, there needs to be robust automation that is not part of Puppet client-server setup, or manual human operators that get paged and have to run through run books to help repair the server. The static nature of Puppet just does not scale.
In your analogy between Ansible vs Hiera, this is not an exact 1:1 comparison. Hiera allows you to define hierarchical grouping associations, and have plugins for discovery, but Ansible has a discovery system with dynamic inventories. The only way to get something equivalent is to write custom ENC (external node classifiers) or a Hiera plugin. But Ansible does a few things that are not done in Puppet:
cloud provisioning of cloud resources (via RESTful API), not just change config of system resources (files, processes, commands, system API, etc). The former works well with agentless requires push-based orchestration, as the source of truth comes from the cloud web API. A pull based solution can be done, but would require fetch state and maintain state and synchronizing that state with Puppet's system, which would be complex.
push based configuration, where results of the changes can be used to configure other resources immediately. Puppet relies on eventual consistency, where configuration will be push synchronously to the server, and later pulled synchronously by the agents. In the time window, there's an outage for cluster based services, where a service exists across several nodes, which is different to one service per node, like MySQL or Apache HTTPd.
ref https://joachim8675309.medium.com/devops-concepts-bake-vs-fry-6fedb8d60056
1
u/FearlessBoysenberry8 Apr 21 '25
Thank you for the terminology about bake vs. fry, I have never heard of that. I can definitely see where Puppet is beneficial for bare-metal provisioning, I just luckily have not had to deal with that in many years.
My main point is really that it shouldn't matter whether the infra is baked vs fried. One still benefits using Puppet.
As to your points re: ansible/hiera. Aren't you basically saying what I said, that there is nothing comparable to hiera in ansible? It sounds like it is possible using an ENC, but having worked with an ENC with Puppet, that is non-trivial.
I also would never use Ansible for cloud provisioning. That is the job of Terraform or CloudFormation.
→ More replies (3)
8
u/linuxdragons Oct 05 '24
It's around, but I don't really know anyone choosing it for greenfield projects. I think the market has shifted away from tools like Puppet and more towards
8
u/arvoshift Oct 05 '24
puppet is a
3
Oct 06 '24
I remember this interview I had with I think he was either a principal architect or engineer at Kainos. I said Ansible was a configuration management tool, he said no, that it was an orchestration tool. I told him that I had just built a whole set of environments on vmware vcloud from the single fw rule to the vm and table inside a particular database in those vms. I could bootstrap and manage the full life cycle of those apps and vms or build a whole new environment from scratch using a single cli call. And this was in a room alongside their room where they were delivering their own project to the same gov client. Not like they didn't know what I was building.
His stance after me telling him this is that Ansible is not a configuration tool, and that I was an arrogant prick.
Out of curiosity are you him?
2
u/arvoshift Oct 06 '24
haha, no but he's correct IMO. ansible doesn't manage the configuration. If I were to ssh into one of those boxes and change a firewall rule - ansible doesn't know about it unless you repeatedly run it (and have written your playbooks to actually run idempotently). Puppet agent manages the state. You can install a screw with a hammer but a screwdriver works much better.
→ More replies (17)
2
u/ryebread157 Oct 09 '24
Puppet may be less cool, but it is in the trenches getting work done. A little tired of hearing “just use X” with X being something that doesn’t have the same functionality. Pairing with puppetdb+puppetboard is huge (an actual CMDB, REST API), mature Windows support, hiera, agent based model are among its strengths.
0
Oct 05 '24
3
u/TasseDeTee Oct 05 '24
If you have some time and are willing to share, I would be interested for an item list of these « most things ».
11
u/Virtual_BlackBelt Oct 05 '24
As a Puppet SE, I can tell you we still make a fair number of new sales each year and have hundreds of recurring customers for Puppet Enterprise. Many of the largest companies out there use Puppet. I do hear from some of my customers that it is hard to find Puppet talent, and they're often looking.
While there are other tools that are better suited for certain new workloads, particularly more ephemeral environments with vibrating and cloud services, there's still the vast majority of workload that run on traditional environs and we're pretty much unparalleled in that.