After including WordPress in my puppet configuration, I noticed that puppet runs were taking significantly longer than before. I had included WordPress in puppet to facilitate easy upgrades and make a consistent publishing system for multiple independent blogs. I wasn’t aware of the network features of WordPress when I set this up, but in hindsight I would do it this way again, as management is painless. I may experiment with the network feature in the future.

To keep the flexibility of puppet without making all puppet runs take longer and longer, I moved the WordPress configuration to a separate manifest that is applied manually as needed.

To begin I created a manifest called manual-wordpress.pp that contains the following:

import "classes/*"

node 'host.example.com' {
    wordpress { "blog.shanemeyers.com":
        domain => "blog.shanemeyers.com",
        path => "/path/to/blog.shanemeyers.com",
        db => "database_name",
        db_user => "dbuser",
        db_pass => "dbpass",
    }
}

This manifest includes the node directive to ensure that the blog is installed only on the host I want it installed on. The manual-wordpress.pp could be considered to be an equivalent of the site.pp file.

Under classes/ I have the same wordpress.pp file as mentioned in the installing WordPress via puppet post.

To complete the task of applying the manual manifests, I created a PHP script that calls puppet as follows:

sudo /usr/bin/puppet --color html --verbose 
    /path/to/manual-wordpress.pp

Puppet should be run as root to enable the puppet client to access the host’s SSL key files and therefore communicate with the puppet master for retrieving files.