Return to

Why Puppet?

Hey y’all!

I am currently writing an assignment on the topic of optimizing IT infrastructure management by using Puppet and in need of some inspiration. Maybe a quick discussion can help me.
What do you guys think are benefits of using such a software and why and for what is Puppet better, than contenders?

I would greatly appreciate some input.


I use Chef and Puppet at work. But mostly Chef.

The main benefits I like are:

  1. Deploying the same thing across a large estate of servers is much easier - From an operational perspective running chef-client on each server is much nicer, and more efficient, than running a whole list of commands. Which moves me on the my second point.

  2. Less prone to human error - Eliminates mistyping/pasting of commands when deploying. Of course errors can arise in the cookbook/runbook. However with thorough testing, much less likely.

  3. Keeping servers “in sync” - As Chef manages how a server in a particular environment should be configured. It keeps all those servers working in symmetry.

That’s just a few of the top-of-my-head.

1 Like

I suggest you search the Web, since much has been written on this topic. Still, I will add to BigBlueHouse’s good observations.

  1. Repeatability and consistency of machine configurations.

  2. Documentation - a record of the machine configurations.

  3. Version control

  4. Keeping server configuration “in sync” with the specified configuration. (Correct any discrepancies that arise, probably human-made changes that weren’t incorporated into configuration management.) I respectfully suggest this revision to BigBlueHouse’s #3, since configuration management systems like Puppet & Chef can not ensure the specified configuration is good, or keeps machines “working in symmetry”. But it does allow the IT folks to develop & enforce a configuration that does.

  5. Useful not only for servers, but for any client machines managed by the IT folks.

Hope the suggestions you get here are helping in kick-starting your writeup.

1 Like

Puppet is great for large server deployments, as you can simply connect all the VMs to the master server, so they can easily perform self-configuration and so it’s easy to manage. New to add that others did not mention: this has an added bonus of being capable of easily handling a mixed-OS farm.

As opposed by something like Ansible, which does not really have a master server (unless you have something like Tower or similar, but they are initiators and apply the updates), and it primarily works over SSH. Windows servers are harder, since you have to configure either SSH or WinRM for it to work, which is extra work over something like Puppet. But Ansible is fantastic for smaller deployments that are Linux only.

Wow, thanks for your great input guys, I really appreciate it!

I use puppet on quite a regular basis and agree with your arguments, as to why it is very good. It works very well with out quite large server environment and configures many different systems in a very uniform way.
But unfortenately I don’t have any experience with other tools, such as Ansible.

@DevBlox From a Linux-only standpoint, would you say, that Ansible is a better choice for smaller deployments, because of its small footprint and it’s relatively easy setup in contrast to Puppet?

@Caped_Kibitzer I actually have not thought of using Puppet as a client management solution. Don’t you think, that Puppet would be quite a bit heavy for client devices, especially if we’re talking about portable machines like Notebooks?

I actually use Ansible these days, and am speaking to configuration-management (C-M) software generally, rather than Puppet specifically. One use case for client machines is configuration of “golden images” which are the basis for installation on multiple clients. C-M is/was often used with Vagrant to configure VMs. Workstations configured with C-M tools get many of the same benefits as servers - probably would emphasize a core configuration, not “controlling all the things”.

I have no experience or firm opinion on the use of C-M tools to manage numerous notebooks. But wouldn’t it be desirable for these to have known, repeatable configurations? I have the impression that different tools are emerging to address similar goals for that class of machines.

IMO, Ansible is not as good as a client/server model like Puppet, Salt, and Chef. Ansible is good for developer environments and small teams. For larger infrastructure or larger teams, Puppet is definitely a better option

It’s also very good for client devices because you can provision users, accounts, groups, etc. pretty easily with Puppet modules. Some may argue it’s easier with Ansible. I definitely prefer Puppet. The setup takes longer, but after you’re established, it’s hard to go wrong.

From a Linux-only standpoint, Ansible is better, period.

It’s agentless, it doesn’t require a management server, and it’s efficient.

That’s not to say ansible doesn’t have downsides, but I’ve only ever had difficulty with chef and puppet. Ansible’s always done what I asked it to do.

That would be really nice and I get the same impression as you. I guess from a broader perspective, client management and server- or infrastructure management is basically the same thing. So why not use the tools you have already?

I think so, too. I have to admit, that I’ve not yet worked that much with Ansible (or any other tool for that matter), so I can’t really comment on working with it. But that’s a thing, which I definitely plan on doing in the future.
Puppet is, what I have used at work for years now and I guess I am very fond of it primarily because I have used it exclusively.

From reading your comments I get the general impression, that Ansible is perfect for getting the show on the road quickly and easy, because of the lack of dependencies and agentless deployment. But I guess, that there are many pros and cons to be compared with both tools.

Thank you all for your input so far, it really helps igniting that spark!

1 Like