Puppet Enterprise – upgrading all agent nodes automatically

Picture the scene…

There's a new release of Puppet Enterprise. You download it, run the upgrade in your test environment, run your regression tests, and all looks good. You then upgrade your production master – all looks good. All that remains to be done is to upgrade the pupept agent on all client nodes – all 750 of them.

Now, you could ssh to each node individually and run the PE installer via curl|bash. You could even automate that with pssh, or similar. But there's got to be a better way, right?

This was the position I found myself in earler this week.

I did some digging and found the puppet_agent module which, on the face of it, is written for just this situation. However, the module specifically doesn't automatically upgrade PE if the existing client is running v4.x.x but it *will* upgrade if a package version is passed to the module. Also, by default, it creates a new yum repo file pointing at the upstream Puppet repos which is not necessary on PE installs since the agent packages are already present on the master and available at https://<PUPPET_MASTER>:8140/packages/<PE_VERSION>/<OS+ARCH>/. In fact the PE install process creates a yum config pointing at this repo. This is not upgraded when the master is upgraded.

So, to summarise, I need to solve two issues:

  1. Create a yum config pointing at the new agent software on the master
  2. Pass the specific package version to the puppet_agent class.

I noticed on the puppet master under packages that, in addition to the versioned directories, there was a current link which points to the, er, "current" version of the agent. I also noticed that there was a top-level fact called platform_tag that defined the <OS+ARCH> combination. That gave me enough information to create a repo config that will always point to "current" agent software on the master.

Digging in the puppet_agent class, I found that it used a PE function pe_compiling_server_aio_build() to get the agent version available on the master. I now have all the information I need.

I wrote the following code in my profile::puppet_agent class, which is applied to all nodes:

  yumrepo { 'pe_repo':
    ensure    => present,
    baseurl   => "https://${::puppet_master_server}:8140/packages/current/${::platform_tag}",
    descr     => 'Puppet Labs PE Packages $releasever - $basearch',
    enabled   => 1,
    gpgcheck  => 1,
    gpgkey    => "https://${i::puppet_master_server}:8140/packages/GPG-KEY-puppetlabs",
    proxy     => '_none_',
    sslverify => false,
  class{ '::puppet_agent':
    manage_repo     => false,
    package_version => pe_compiling_server_aio_build(),

As if by magic, all my client nodes were upgraded to the latest agent software.

Auto-renewal of a Let’s Encrypt certificate

I configured this blog to use a free, automatically-issued Let's Encrypt SSL certificate around 6 months ago.

The command to issue the cert is as follows:

letsencrypt-auto certonly 
  -a webroot 
  --webroot-path /var/www/sites/blog.yo61.com/html/ 
  -d blog.yo61.com 
  --email robin.bowes@example.com

To check if an existing certificate will expire within the next 28 days, use this command:

openssl x509 
  -checkend 2419200 
  -inform pem 
  -in /etc/letsencrypt/live/blog.yo61.com/cert.pem

Put these together, and run from a daily cron job (remembering to restart your web server after changing the certificate) and your cert will automatically renew 28 days before it expires.

openssl x509 
  -checkend 2419200 
  -inform pem 
  -in /etc/letsencrypt/live/blog.yo61.com/cert.pem || 
letsencrypt-auto certonly 
  -a webroot 
  --webroot-path /var/www/sites/blog.yo61.com/html/ 
  -d blog.yo61.com 
  --email robin.bowes@example.com && 
systemctl restart httpd

WordPress with php-fpm under Apache 2.4

I recently migrated this blog to a new server running CentOS 7 and decided to use php-fpm and mod_proxy_fcgi instead of mod_php. I also like to install WordPress in its own directory and had problems getting the wp-admin sections of the site to work. I figured it out eventually with help from this page: https://wiki.apache.org/httpd/PHPFPMWordpress

This is the complete apache config fragment that defines the vhost, including SSL:

<VirtualHost *:443>
  ServerName blog.yo61.com

  ## Vhost docroot
  DocumentRoot "/var/www/sites/blog.yo61.com/html"

  ## Directories, there should at least be a declaration for /var/www/sites/blog.yo61.com/html

  <Directory "/var/www/sites/blog.yo61.com/html">
    AllowOverride FileInfo
    Require all granted
    DirectoryIndex index.php
    FallbackResource /index.php

  <Directory "/var/www/sites/blog.yo61.com/html/wordpress/wp-admin">
    AllowOverride None
    Require all granted
    FallbackResource disabled

  ## Logging
  ErrorLog "/var/log/httpd/blog.yo61.com_https_error_ssl.log"
  ServerSignature Off
  CustomLog "/var/log/httpd/blog.yo61.com_https_access_ssl.log" combined

  ## SSL directives
  SSLEngine on
  SSLCertificateFile      "/etc/letsencrypt/live/blog.yo61.com/cert.pem"
  SSLCertificateKeyFile   "/etc/letsencrypt/live/blog.yo61.com/privkey.pem"
  SSLCertificateChainFile "/etc/letsencrypt/live/blog.yo61.com/chain.pem"
  SSLCACertificatePath    "/etc/pki/tls/certs"

  ## Custom fragment
  ProxyPassMatch ^/(.*.php(/.*)?)$ fcgi://$1
  Header always set Strict-Transport-Security "max-age=63072000; includeSubdomains; preload"
  Header always set X-Frame-Options DENY
  Header always set X-Content-Type-Options nosniff

sudo, pipelines, and complex commands with quotes

We've all run into problems like this:

$ echo 12000 > /proc/sys/vm/dirty_writeback_centisecs
-bash: /proc/sys/vm/dirty_writeback_centisecs: Permission denied

The command fails because the target file is only writeable by root. The fix seems obvious and easy:

$ sudo echo 12000 > /proc/sys/vm/dirty_writeback_centisecs -bash: /proc/sys/vm/dirty_writeback_centisecs: Permission denied

Huh? It still fails. What gives? The reason it fails is that it is the shell that sets up the re-direction before running the command under sudo. The solution is to run the whole pipeline under sudo. There are several ways to do this:

echo 'echo 12000 > /proc/sys/vm/dirty_writeback_centisecs' | sudo sh
sudo sh -c 'echo 12000 > /proc/sys/vm/dirty_writeback_centisecs'

This is fine for simple commands, but what if you have a complex command that already includes quotes and shell meta-characters?

Here's what I use for that:

sudo su <<EOF
echo 12000 > /proc/sys/vm/dirty_writeback_centisecs

Note that the backslash before EOF is important to ensure meta-characters are not expanded.

Finally, here's an example of a command for which I needed to use this technique:

sudo sh  << EOF
perl -n -e '
use strict;
use warnings;
if (/^([^=]*=)([^$]*)(.*)/) {
  my $pre = $1;
  my $path = $2;
  my $post = $3;
  (my $newpath = $path) =~ s/usr/usr/local/;
  $newpath =~ s/://g;
  print "$pre$newpath:$path$postn"
else {
' < /opt/rh/ruby193/enable > /opt/rh/ruby193/enable.new

Conditionally running cron tasks based on arbitrary conditions

Volcane recently asked in ##infra-talk on Freenode if anyone knew of "some little tool that can be used in a cronjob for example to noop the the real task if say load avg is high or similar?"

I came up with the idea to use nagios plugins. So, for example, to check load average before running a task:

/usr/lib64/nagios/plugins/check_load -w 0.7,0.6,0.5 -c 0.9,0.8,0.7 >/dev/null && echo "Run the task here"

Substitute the values used for the -w and -c args as appropriate, or use a different plugin for different conditions.

Atomic Deployment of Puppet environments

In a previous post, I described how to describe puppet environments, roles, and profiles, as modules and how to use r10k and librarian-puppet to deploy them.

One possible problem with deploying to the puppet environment directory directly is that the librarian-puppet run can take some time and there is a possibility that puppet may attempt to compile a catalogue in an incomplete or inconsistent environment. One way to overcome this is to deploy the environments into a new directory, create a symlink, and move the symlink atomically into place.

This would look something like this:

cd /etc/puppet/envs
# create a new dir under /etc/puppet/envs - I use a timestamp in the name so I know when it was created
NEW_ENV_DIR=$(mktemp --directory envs.$(date -Isec).XXX")
cd /etc/puppet
# use r10k deploy the environments into the new dir
PUPPETFILE_DIR="envs/${NEW_ENV_DIR}" r10k puppetfile install
# loop over all the environments and use librarian-puppet to deploy all the roles/profiles/modules
while read env ; do
  pushd $env
  LIBRARIAN_PUPPET_PATH=modules librarian-puppet install --no-use-v1-api --strip-dot-git
done < <(find "/etc/puppet/envs/${NEW_ENV_DIR}" -maxdepth 1 -mindepth 1 -type d)
ln -s /etc/puppet/envs/${NEW_ENV_DIR} /etc/puppet/envs/environments
mv /etc/puppet/envs/environments /etc/puppet

I have written a script that does all of this in a more robust way and also uses parallel to speed up the deployment process.

The script and the role and profile modules references in my previous article are in this github repo.

Recursive deployment of puppet environments with r10k and librarian-puppet

By treating roles and profiles as puppet modules, we can use r10k and librarian-puppet to manage the deployment of our puppet code into our puppet environements.

I shall assume that puppet is configured to use to use directory environments and that the environment path is $confdir/environments (ie. the default location). I also assume that both r10k and librarian-puppet are installed and in the path.

You should also understand and embrace the role-profile-module pattern, first described by Craig Dunn and subsequently by Adrian Thebo and Gary Larizza. Quoting Gary:

  • Roles abstract profiles
  • Profiles abstract component modules
  • Hiera abstracts configuration data
  • Component modules abstract resources
  • Resources abstract the underlying OS implementation 

I find the following points useful to clarify the purpose of each of the layers in this model:

  • Roles, profiles, and component modules can all be implemented as puppet modules
  • Each node is assigned exactly one role (either in site.pp or, preferably, using some external node classifier)
  • Each role includes one or more profiles
  • Each profile loads configuration data and feeds it into the component modules – this is where your business logic should go
  • Each component module should be generic and contain no site-specific data. You should be able to publish all your component modules on PuppetForge without leaking any secrets.

We can further extend this model to include environments. An environment can be thought of as a group of roles and can also be implemented as a puppet module.

So, how do we set this up?

At the top-level, we put a Puppetfile in the puppet config dir containing a list of our environments. This will look something like this:

#!/usr/bin/env ruby
#^syntax detection

forge 'https://forgeapi.puppetlabs.com'

mod 'yo61-env_production',
  :git => 'git@github.com:yo61/puppet-demo_env_production.git'

mod 'yo61-env_staging',
  :git => 'git@github.com:yo61/puppet-demo_env_staging.git'

Each environment is defined as a puppet module. Any valid Puppetfile syntax may be used to specifiy the module location, including alternate branches or specific version tags. 

Each of the environment modules should contain all the usual things you would put in a puppet environment, eg. a manifests/site.pp, etc. as well as a Puppetfile containing a list of all the roles to be deployed to this environment. The Puppetfile for a simple environment would look something like this:

#!/usr/bin/env ruby
#^syntax detection

forge "https://forgeapi.puppetlabs.com"

# list all the roles that are included in this environment
mod 'yo61-role_default',
  :git => 'git@github.com:yo61/puppet-demo-roles-profiles.git',
  :path => 'modules/role_default'

mod 'yo61-role_foo',
  :git => 'git@github.com:yo61/puppet-demo-roles-profiles.git',
  :path => 'modules/role_foo'

mod 'yo61-role_bar',
  :git => 'git@github.com:yo61/puppet-demo-roles-profiles.git',
  :path => 'modules/role_bar'

Like the top-level Puppetfile used to defined environments, each role is defined as a puppet module.

Each of the role modules will contain a simple class that loads the profiles used by the role, and a Puppetfile containing a list of all profiles used by the role. The Puppetfile for a simple role would look something like this:

#!/usr/bin/env ruby
#^syntax detection

forge "https://forgeapi.puppetlabs.com"

# list all the profiles that are included in this role
mod 'yo61-profile_common',
  :git => 'git@github.com:yo61/puppet-demo-roles-profiles.git',
  :path => 'modules/profile_common'

Each of the profile modules will contain all the puppet code required to define the business logic, load configuration data, etc. and a Puppetfile containing a list of all the component modules used by the profile. The Puppetfile for a simple profile would look something like this:

#!/usr/bin/env ruby
#^syntax detection

forge "https://forgeapi.puppetlabs.com"

# include all the modules used by this profile
mod 'puppetlabs-stdlib',
mod 'stahnma-epel'
mod 'puppetlabs-ntp'

Again, any valid Puppetfile syntax may be used.

We've now defined all our environments, roles, and profiles and we're ready to deploy each environment.

First, we run r10k to deploy each of the environment modules into the environment dir (/etc/puppet/environments):

# switch to the location of the top-level Puppetfile
cd /etc/puppet
PUPPETFILE_DIR=/etc/puppet/environments r10k puppetfile install

This will create a directory in /etc/puppet/environments for each of the environments defined in the top-level Puppetfile.

Next, we change into each of the newly-created environment directories and run librarian-puppet to install all the roles required by that environment.

cd /etc/puppet/environments/production
LIBRARIAN_PUPPET_PATH=modules librarian-puppet install --no-use-v1-api --strip-dot-git

The best bit is that librarian-puppet supports recursive module dependency resolution so this one command installs not only the roles, but also all the profiles, and component modules required by each of the roles.

My next article will present a script that runs r10k and librarian-puppet as described in this article, and also updates puppet environments atomically


Finding “old” nodes in puppetdb

We're using puppet + puppetdb in an EC2 environment where nodes come and go quite regularly. We have a custom autosign script that uses ec2 security info to validate the nodes before allowing the autosigning. This is all good, but it can leave a lot of "dead" nodes in puppet, eg. if a bunch of nodes are created by an autoscale policy and then terminated.

To get rid of these zombie nodes from puppet/puppetdb we can just use:

puppet node deactivate <certname1> <certname2> ... <certnameN>

We can query puppetdb to get a list of nodes that have not sent puppet reports for, say, 24 hours. The puppetdb query we need is something like this:

'query=["<", "report-timestamp", "$cutoff_date"]'

where $cutoff_date is a date in ISO8601 format, eg. 2015-03-05T13:39:45+0000

We can use date to generate the cutoff date with something like this:

$cutoff_date=$(date -d '-1 day' -Isec)

We then plug this into the query string and send it with curl as follows:

curl --silent -G 'http://localhost:8080/v4/nodes' 
  --data-urlencode "query=["<", "report-timestamp", "$(date -d '-1 day' -Isec)"]"

Finally, we filter through jq to get a list of certnames:

curl --silent -G 'http://localhost:8080/v4/nodes' 
  --data-urlencode "query=["<", "report-timestamp", "$(date -d '-1 day' -Isec)"]" 
  | jq '.[].certname'

We can then pass the list of nodes to the "puppet node deactivate" command.