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.