Search /
~ / Linux

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…

Published
Author
Graham Barker
Category
Linux
Read
6 min
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

Prerequisites

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 https://yum.puppet.com/puppet7-release-el-8.noarch.rpm

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/puppet-agent.sh

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 https://yum.puppet.com/puppet7-release-el-8.noarch.rpm

Install the puppet agent:

sudo yum install -y puppet-agent

Source the puppet script to configure the system after install:

source /etc/profile.d/puppet-agent.sh

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

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

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 

Questions? Email me (contact@virtualg.uk) or DM me on X (@virtualg_uk).

EOF · Published 2021-01-30
Author
Graham Barker

Graham has spent 20 years in infrastructure, including senior engineering roles at Tesla and Dell Technologies in the UK. He's a VMware Certified Implementation Expert, a 10x VMware vExpert and a moderator on the official Broadcom community forums.