Managing Infrastructure with Puppet - James Loope [14]
:> mc-find-hosts
A.example.com
B.example.com
C.example.com
D.example.com
We can also get some information about our individual MCollective nodes. mc-inventory will tell us what agents are available on a node, what Puppet classes that node is a member of, and assuming the Facter module is installed, a list out all of the available Facter facts about the node:
:> mc-inventory A.example.com
Inventory for A.example.com:
Server Statistics:
Version: 1.0.1
Start Time: Fri May 06 11:10:34 -0700 2011
Config File: /etc/mcollective/server.cfg
Process ID: 22338
Total Messages: 143365
Messages Passed Filters: 75428
Messages Filtered: 67937
Replies Sent: 75427
Total Processor Time: 162.09 seconds
System Time: 73.08 seconds
Agents:
discovery filemgr package
iptables nrpe rpcutil
process puppetd
service
Configuration Management Classes:
ntp php apache2
mysql-5 varnish
Facts:
architecture => x86_64
domain => example.com
facterversion => 1.5.7
fqdn => A.example.com
hostname => A
id => root
is_virtual => true
kernel => Linux
kernelmajversion => 2.6
kernelversion => 2.6.35
This is already a useful tool for diagnostics and inventory on all of your Puppet-managed servers, but MCollective also lets us execute agents on the target systems, filtered by any of these attributes, facts, agents, or classes. For example, if our servers run Apache and we need to restart all of the Apaches on all of our servers, we could use the mc-service agent to do this:
:> mc-service --with-class apache2 apache2 restart
This will place a message on the MCollective message bus that says: “All the servers with the apache2 Puppet class, use your service agent to restart apache2.” We can even add multiple filters like the following:
:> mc-service --with-class apache2 --with-fact architecture=x86_64 apache2 restart
This will let us restart Apache on only the 64bit “x86_64” architecture servers that have the Puppet apache2 class. These sorts of filters make remote execution of tasks on particular subsets of servers very easy.
Of particular interest to those of us running large infrastructures is MCollective’s built-in capacity to run the Puppet agent on the servers. Puppet’s client-server model, in its default configuration, will poll the Puppet Master once every half hour. This is not convenient, for instance, if you would like to use Puppet to coordinate an application release on a group of servers. If you would like some control over the sequence and timing of the Puppet runs, you can use the MCollective puppetd agent and forgo the polling behavior of the agent daemon. Since Puppet is built in to MCollective, it is not necessary to run the agent on boot either. So long as MCollective and Puppet are both installed, we can execute Puppet as we like.
The agent can be downloaded from GitHub at https://github.com/puppetlabs/mcollective-plugins/tree/master/agent/puppetd/ and, as with the Facter plug-in, should be copied to $libdir/mcollective on the servers, preferably using Puppet. Once it’s installed, you will be able to kick off a Puppet run on all or some of your servers with the following command:
:> mc-puppetd --with-class example runonce
If you don’t mind the default polling behavior of the Puppet agent, you can also use the puppetd MCollective agent to selectively enable or disable Puppet on sets of your instances as well as initiate one-off runs of the agent.
* * *
Note
If you still want to have Puppet run on a regular basis to ensure configuration correctness, but need to avoid polling “stampedes,” take a look at the PuppetCommander project at http://projects.puppetlabs.com/projects/mcollective-plugins/wiki/ToolPuppetcommander. It uses MCollective’s puppetd module to centrally coordinate Puppet runs so as to avoid overwhelming a Puppet Master. It will also give you the power to specify which nodes or classes to run automatically.
* * *
Finally, there is an mc-rpc command that serves as