Installing Puppet 4 on Ubuntu 16.04

This guide will walk you through the steps to install open source Puppet 4 in a master-agent setup on Ubuntu 16.04. Through the Puppet master server which runs the Puppet Server software you can control all other servers, called Puppet agent nodes.


To follow the steps mentioned in this article, you will need three Ubuntu 16.04 servers installed on either (physical or virtual) machines, each with a non-root user with sudo privileges.

Puppet Master

One Ubuntu 16.04 server will be the Puppet master. The Puppet master will run Puppet Server, which is resource intensive and requires at least:
  • 4 GB of memory
  • 2 CPU cores
If you want manage larger infrastructures, the Puppet master will definitely require more resources.

Puppet Agents

The remaining two servers will be Puppet agent nodes, managed by the Puppet master. We'll call them dbserver1 and webserver1.

When these three Ubuntu 16.04 servers are in place, you're ready to begin.

Configuring /etc/hosts

Puppet master servers and the nodes they manage need to be able to communicate with each other. In most situations, this will be accomplished using DNS, either configured on an externally hosted service or on self-hosted DNS servers maintained as part of the infrastructure.

DNS is its own domain of expertise, however, even on hosted services, so in order to focus on the fundamentals of Puppet itself and eliminate potential complexity in troubleshooting while you're learning, in this article we'll use the /etc/hosts file instead.

On all three Ubuntu machines, edit the /etc/hosts file. At the end of the file, specify the Puppet master server as follows, substituting the IP address for your Puppet master:

sudo nano /etc/hosts
puppet_ip_address    puppet-master

Save and close.

Installing Puppet Server

Puppet Server is the software that pushes configuration from the Puppet master to the other servers. It runs only on the Puppet master; the other hosts will run the Puppet Agent.

We'll enable the official Puppet Labs collection repository with these commands:

curl -O
sudo dpkg -i puppetlabs-release-pc1-xenial.deb
sudo apt-get update

When apt-get update is complete, ensuring that we'll be pulling from the Puppet Labs repository, we'll install the puppetserver package:

sudo apt-get install puppetserver

Press Y to proceed. Once installation is complete, and before we start the server, we'll take a moment to configure the memory.

Configure memory allocation

By default, Puppet Server is configured to use 2 GB of RAM. You can customize this setting based on how much free memory the master server has and how many agent nodes it will manage.

To customize it, open /etc/default/puppetserver:

sudo nano /etc/default/puppetserver

Then find the JAVA_ARGS line, and use the -Xms and -Xmx parameters to set the memory allocation. We'll increase ours to 3 gigabytes:

JAVA_ARGS="-Xms3g -Xmx3g -XX:MaxPermSize=256m"

Save and exit.

Open the firewall

When you start Puppet Server, it will use port 8140 to communicate, so make sure it's open by executing the following command

sudo ufw allow 8140

Next, we'll start Puppet server.

Start Puppet server

You can execute systemctl command to start Puppet server:

sudo systemctl start puppetserver

This will take some time to complete.

Once you are returned to command prompt, verify puppetserver status

sudo systemctl status puppetserver

You should see a line that says "active (running)" and the last line should look something like:

Dec 07 16:27:33 puppet systemd[1]: Started puppetserver Service.

Now that you've ensured the server is running, let's configure it to start at boot:

sudo systemctl enable puppetserver

With the server running, now you're ready to set up Puppet Agent on our two agent machines, dbserver1 and webserver1.

Installing the Puppet Agent

The Puppet agent software must be installed on any server that the Puppet master will manage. In most cases, this will include every server in your infrastructure.

Enable the official Puppet Labs repository

First you'll enable the official Puppet Labs collection repository with these commands:

dbserver1$ wget
dbserver1$ sudo dpkg -i puppetlabs-release-pc1-xenial.deb
dbserver1$ sudo apt-get update

Install the Puppet agent package

Then, you'll install the puppet-agent package:

dbserver1$ sudo apt-get install puppet-agent

Start the agent and enable it to start on boot:

dbserver1$ sudo systemctl start puppet
dbserver1$ sudo systemctl enable puppet

Now, repeat these steps on webserver1:

webserver1$ wget
webserver1$ sudo dpkg -i puppetlabs-release-pc1-xenial.deb
webserver1$ sudo apt-get update
webserver1$ sudo apt-get install puppet-agent
webserver1$ sudo systemctl enable puppet
webserver1$ sudo systemctl start puppet

Now that both agent nodes are running the Puppet agent software, we will sign the certificates on the Puppet master.

Signing Certificates on Puppet Master

The first time Puppet runs on an agent node, it sends a certificate signing request to the Puppet master. Before Puppet Server will be able to communicate with and control the agent node, it must sign that particular agent node's certificate.

List current certificate requests

To list all unsigned certificate requests, run the following command on the Puppet master:

sudo /opt/puppetlabs/bin/puppet cert list

There should be one request for each host you set up, that looks something like the following:

  "dbserver1.localdomain"  (SHA256) 46:19:79:3F:70:19:0A:FB:DA:3D:C8:74:47:EF:C8:B0:05:8A:06:50:2B:40:B3:B9:26:35:F6:96:17:85:5E:7C
  "webserver1.localdomain" (SHA256) 9D:49:DE:46:1C:0F:40:19:9B:55:FC:97:69:E9:2B:C4:93:D8:A6:3C:B8:AB:CB:DD:E6:F5:A0:9C:37:C8:66:A0

A + in front of a certificate indicates it has been signed. The absence of a plus sign indicates our new certificate has not been signed yet.

Sign requests

To sign a single certificate request, use the puppet cert sign command, with the hostname of the certificate as it is displayed in the certificate request.

For example, to sign dbserver1's certificate, you would use the following command:

sudo /opt/puppetlabs/bin/puppet cert sign db1.localdomain

Output similar to the example below indicates that the certificate request has been signed:

Notice: Signed certificate request for dbserver1.localdomain
Notice: Removing file Puppet::SSL::CertificateRequest dbserver1.localdomain at '/etc/puppetlabs/puppet/ssl/ca/requests/dbserver1.localdomain.pem'

The Puppet master can now communicate and control the node that the signed certificate belongs to. You can also sign all current requests at once.

We'll use the --all option to sign the remaining certificate:

sudo /opt/puppetlabs/bin/puppet cert sign --all

Now that all of the certificates are signed, Puppet can manage the infrastructure.

Verifying the Installation

Puppet uses a domain-specific language to describe system configurations, and these descriptions are saved to files called "manifests", which have a .pp file extension. We'll create a brief directive to verify that the Puppet Server can manage the Agents as expected.

We'll begin by creating the default manifest, site.pp, in the default location:

sudo nano /etc/puppetlabs/code/environments/production/manifests/site.pp

We'll use Puppet's domain-specific language to create a file called it_works.txt on agent nodes located in the tmp directory which contains the public IP address of the agent server and sets the permissions to-rw-r--r--:

site.pp example
file {'/tmp/it_works.txt':                        # resource type file and filename
  ensure  => present,                             # make sure it exists
  mode    => '0644',                              # file permissions
  content => "It works on ${ipaddress_eth0}!\n",  # Print the eth0 IP fact

By default Puppet Server runs the commands in its manifests by default every 30 minutes. If the file is removed, the ensure directive will cause it to be recreated. The mode directive will set the file permissions, and the content directive add content to the directive.

We can also test the manifest on a single node using puppet agent --test. Note that --test is not a flag for a dry run; if it's successful, it will change the agent's configuration.

Rather than waiting for the Puppet master to apply the changes, we'll apply the manifest now on db1:

sudo /opt/puppetlabs/bin/puppet agent --test

The output should look something like:

Info: Using configured environment 'production'
Info: Retrieving pluginfacts
Info: Retrieving plugin
Info: Loading facts
Info: Caching catalog for db1.localdomain
Info: Applying configuration version '1481131595'
Notice: /Stage[main]/Main/File[/tmp/it_works.txt]/ensure: defined content as '{md5}acfb1c7d032ed53c7638e9ed5e8173b0'
Notice: Applied catalog in 0.03 seconds

When it's done, we'll check the file contents:

cat /tmp/it_works.txt

It works on!

Repeat this for webserver1 or, if you prefer, check back in half an hour or so to verify that the Puppet master is running automatically.

Note: You can check the log file on the Puppet master to see when Puppet last compiled the catalog for an agent, which indicates that any changes required should have been applied.

tail /var/log/puppetlabs/puppetserver/puppetserver.log

Output excerpt

2016-12-07 17:35:00,913 INFO  [qtp273795958-70] [puppetserver] Puppet Caching node for webserver1.localdomain
2016-12-07 17:35:02,804 INFO  [qtp273795958-68] [puppetserver] Puppet Caching node for webserver1.localdomain
2016-12-07 17:35:02,965 INFO  [qtp273795958-68] [puppetserver] Puppet Compiled catalog for webserver1.localdomain in environment production in 0.13 seconds

We've successfully installed Puppet in Master/Agent mode.

No comments:

Powered by Blogger.