Getting started with Puppet 7 Open Source and VMware

Puppet is a great automation tool for managing all of your Virtual Machines. Puppet Open Source is free and supports the management of most operating systems from Windows, Linux and Mac. This post guides you through the installation and shows how to create a basic configuration to get started with managing your virtual machines. Puppet also has many bolt-ons which enables you to use Puppet with VMware, helping you to automate the management of everything in the datacenter.

Installing Puppet Open Source Server


I’m using a new CentOS 8 VM to deploy the puppet server. You can use other operating systems but you’ll need to adjust the steps below to suit.

First, ensure you have the following setup on your CentOS server:

  • Static IP address
  • Hostname
  • Correct DNS server(s) configured
  • NTP configured
  • Another VM to test puppet with (An agent VM)

Install Puppet Server

For CentOS 8, we need to install the correct repo for Puppet 7:

 sudo rpm -Uvh 


Next, install the server software:

 sudo yum install -y puppetserver 



Once puppet is installed, ensure it is configured to start on boot

 sudo systemctl enable puppetserver 


Run the following to configure the puppet server

 source /etc/profile.d/ 


And start the server

 sudo systemctl start puppetserver 


You can restart it with the below command if required

 sudo systemctl restart puppetserver 


Puppet Agent Installation

On your test VM, we will now install the puppet agent and connect it to the puppet server.

Setup the puppet repo:

 sudo rpm -Uvh 


Install the puppet agent:

 sudo yum install -y puppet-agent 


Source the puppet script to configure the system after install:

 source /etc/profile.d/ 


Set the puppet server with the following puppet command:

Replace puppet.lab.local with the hostname of your puppet server, ping it first to be sure it resolves to an IP address

 puppet config set server puppet.lab.local –section main 


If you get a “No route to host” error, then ensure the VM can resolve the DNS name you specified above for the puppet server. Also, ensure that port 8140 is open on the puppet server.

You can open TCP port 8140 on the puppet server as follows:

Be aware that this might need to be changed, depending on your security requirements and firewall configuration

 sudo firewall-cmd –zone=public –permanent –add-port=8140/tcp   sudo systemctl restart firewalld 


You should get an error stating that you need to sign the SSL certificate for the agent VM.

To sign the certificate, on the puppet server run the following command

Replace centos-vm-1.lab.local with your agent VM’s name

 puppetserver ca sign –certname centos-vm-1.lab.local 


Looking back on the agent VM, you should see that the SSL certificate has been signed.

If you do not see this, just run the command again:
 puppet config set server puppet.lab.local –section main 

Creating puppet packages for deployment

Here we will create a puppet package and link it to our agent VM. This will demonstrate the power and core features of puppet.

The chrony example

For this example,we are going to use puppet to ensure that the time is synced up to NTP servers. CentOS 8 uses chrony for this rather than the older ntpd service

Once you have this example working, you can use it as a baseline for other things that you want to manage with puppet.

Ensure chrony is not installed

First check that chrony is not installed on the CentOS VM. It probably is, so remove it for the demo.

 sudo systemctl status chronyd 


 sudo dnf remove chrony 

A note on environments

You can and should make other environments and store different configurations in different environments.

IMPORTANT: On the agents, for this example to work, ensure you place them in the production environment. If you have created other environments, then reflect that change in the command below:

On your client/agent VMs edit your puppet configuration file as required:

 vi /etc/puppetlabs/puppet/puppet.conf 
[main] server = puppet.lab.local
certname = centos-vm-1.lab.local
runinterval = 1h
environment = production

Puppet manifest files

With your agents now in the production environment, we can create a config to push to them.

Use vi or another editor to create a file named chrony.pp with the below contents (changing the NTP  server pool config as required)

Since we have placed our agent VMs in the production environment, you’ll want to save the file in the production manifests folder for this example: /etc/puppetlabs/code/environments/production/manifests/chrony.pp

# Class Definition
class chrony {
# Ensure chrony is installed
package {“chrony”:
ensure=> “present”,

# Ensure NTP configuration is correct
file {“/etc/chrony.conf”:
ensure=> “present”,
content=> “pool”,

# Ensure chronyd service is running
service {“chronyd”:
ensure=> “running”,

# Declare Class
include chrony

As you can see, this will:

  • Ensure chrony is installed
  • Ensure a chrony configuration file exists
  • Ensure a config entry for the correct pool exists
  • Ensures that the chronyd service is running

Save the file

Check for syntax errors with:

 puppet parser validate /etc/puppetlabs/code/environments/production/manifests/chrony.pp 

Apply the configuration in noop mode

Next, run the puppet command on the agent VM to test what would happen without actually changing anything. You could, of course, use a new “testing” environment, instead of saving the file earlier directly in the “production” environment.

This would be my suggestion if you are going to use puppet in a real-world scenario as you would want to test the configurations before putting them into the production folder.

This command will force the agent VM to get the latest configuration and apply it in NOOP mode, meaning that it will test to see what would happen if you were running it for real

Note that the –test option here, means do it now rather than wait for the schedule to kick in. It has nothing to do with testing, it’s just used to force the command tor un now.

 puppet agent –test –noop 

You will see that our config would have been applied because the status was different for more than one element of the configuration

Now we can run the command for real, to update our clients (agent VMs) with this configuration:

You can of course, just wait for the scheduler to run and update automatically (every 30 minutes by default)

 puppet agent –test 

You should see that it has been applied successfully.

Also, note here that it was applied to the production environment

Now check to see if chrony is installed and running:

 sudo systemctl status chronyd 

And that’s all we need to do.

Some other notes

For other manifest configurations, just save them in the correct environment folders and let the built-in puppet scheduler apply them.

Be sure the first save them in a “test” or “staging” environment and run them in a testing mode on an agent before rolling them out to every other server in your network!

If your agent is linked to the “production” puppet environment but you want to test the agent VM against a manifest in a “testing” environment, then on the agent you would run:

puppet agent –test –environment testing –noop

If you omit the –environment option, then the command will run with whatever environment the system is assigned to.

To find the environment that a test is assigned to, you can check and change it in the puppet configuration file on the agent VM as we did above

 vi /etc/puppetlabs/puppet/puppet.conf 


In the next post, we will explore how to configure VMware to work with Puppet so that we can automatically provision new VMs.

Be sure to subscribe to be alerted of new posts on the blog and for the weekly newsletter 


Leave a Response

This site uses Akismet to reduce spam. Learn how your comment data is processed.