Managing Infrastructure with Puppet - James Loope [12]
* * *
In this example, Alice will have an account on A.example.com and both Alice and Bob will have users created on B.example.com. In this way, we can distribute users with ssh keys and privilege credentials to our servers in a uniform and automated manner:
class webusers {
Useraccount <| groups == "web" |>
}
class dbusers {
Useraccount <| groups == "db" |>
}
node "A.example.com" {
include webusers
}
node "B.example.com" {
include webusers
include dbusers
}
Throw Away the Handwritten Notebooks
Now that you’ve learned some Puppet and implemented an automation that does something useful, I’d like to talk about what it all means in the real world. Configuration management has been around for a long time, but its nature is changing. When we used to talk about configuration management, it involved checklists and difficult to test scripts. Often the policy documents regarding these topics were where 90% of the effort landed, and even those were not well adhered to. In the new structure that modern automation provides us, the system configuration can be treated like code. We can put it in version control, write functional testing suites for it, and QA it just like application releases. Configurations can have releases that relate to application code releases in meaningful ways, and bugs are easier to identify because we have explicit records of changes. So throw away the handwritten server log, and stop making cowboy changes to production servers. There is a better way.
Chapter 4. MCollective
Puppet is not the end of this journey. We can abstract even further if we begin to talk about pools of servers and virtual instances. What if we have a cluster of application nodes that need to be managed as groups or if we need reporting of Facter variables from all of the nodes that include a certain Puppet class? What do we do if Apache needs a kick on 25 instances out of 1000? MCollective can do these things and more.
MCollective uses a publish/subscribe message bus to distribute commands to systems in parallel. It’s used to push requests or commands out to all of your systems at once, allowing the MCollective server to decide which of the messages it should execute, based on a set of filters in the message. A good analogue of this is an IRC chat service. We can chat in a channel and receive all the messages, but messages that are intended for us will have our name attached to them.
The messages that an MCollective server consumes are then passed on to agent modules that consume the message parameters and then do some work. Agents exist for all sorts of behaviors, such as managing running services; running Puppet; managing packages, processes, and files; and even banning IP addresses with iptables. Beyond this, the agents are fairly simple to write using SimpleRPC.
Getting the Software
MCollective installation is not as simple as Puppet was. We need to set up a Stomp messaging server and configure the MCollective server on each of our hosts before we can start using it.
ActiveMQ
ActiveMQ is Apache’s Java messaging server. We’ll need to install the Sun Java Runtime, get the ActiveMQ package, and configure it. If you’re running Ubuntu, the package sun-java6-jre can be downloaded from the partner repository. You can download an ActiveMQ tar from http://activemq.apache.org/activemq-542-release.html.
Once you have Java installed and the tarball extracted, you’ll need to edit the conf/activemq.xml file and add some authentication details to it. I’ll include an example below; the pertinent portions being the creation of an authorization user for MCollective and the MCollective topic. These are necessary to allow MCollective servers and client to talk to one another. You’ll need these credentials for your MCollective configuration as well: