This page describes MCollective’s components and global configuration.
The architecture of MCollective is based around three main components: servers, clients, and the middleware. Servers and clients also use various sub-components, which are mentioned in their respective sections.
Terminology notes: If you’re familiar with Puppet, note that MCollective uses the term “server” a bit differently.
- Instead of thinking “web server” or “puppet master server,” think “SSH server.” These are machines that mainly perform some other business purpose, but are also listening for MCollective requests.
- From the user’s perspective, servers accept inbound requests and react to them. From the middleware’s perspective, servers are just another kind of client — they proactively initiate a connection and subscribe to the types of messages they care about.
The term “agent” is also different. In Puppet, the agent is a daemon that fetches and applies configurations — the equivalent of the
mcollectivedserver daemon. In MCollective, an agent is just a bundle of actions distributed as a plugin.
Thing Puppet MCollective Service that makes changes to the system puppet agent
Plugins that enable new actions/functionality types and providers agent plugins
An MCollective server (often just called a “node”) is a computer that can be controlled via MCollective. Servers run the MCollective daemon (
mcollectived), and have any number of agent plugins installed.
mcollectived service uses several kinds of plugin:
The connector and security plugins are mandatory, and the clients must use the same plugins as the servers.
Servers can also use:
An MCollective client can send requests to any number of servers, use a security plugin to encode and sign the request, and use a connector plugin to publish it. These plugins must match the security and connector used by the servers. The client can also receive replies from servers and format the response for a user or some other system.
The most common client is the
mco command-line client, which can be used interactively or in scripts. You can also write clients in Ruby, such as backends for GUI apps or glue in a reactive infrastructure.
Like servers, clients use several kinds of plugin:
(As mentioned above, servers use agent plugins to execute actions. Since clients request these actions, they need to know which actions are available and what kinds of arguments they require. To do this, they use the DDL file from each agent they care about. These files describe actions and their inputs to enable early validation, and also tell the client how to format and summarize responses for the user.)
Clients can also use:
MCollective clients and servers don’t communicate directly. They expect to be connected to some middleware system that knows how to route messages, and they publish messages to the middleware and subscribe to messages they need to receive.
This middleware system is external to MCollective, and everything that interacts directly with it is implemented in a connector plugin that needs some information about the middleware’s topology and configuration. As far as everything but the connector is concerned, the middleware is an abstract cloud of magic:
The connector and middleware handle three main kinds of messages:
See the middleware overview page for info about the most common middleware options.
Some MCollective configuration is global, and must match for all components. Deploying will be easier if you figure this configuration out first.
The standard deployment guide makes several of these decisions for you, and goes into greater detail about the rest.
The main kinds of shared configuration are:
All servers and clients must be using the same connector plugin, and it must match the middleware type you’ve chosen for the deployment.
Additionally, the way your middleware is configured will usually dictate some extra settings for the connector plugin. These generally include:
All servers and clients must be using the same security plugin. If it requires credentials for authentication, the servers will have to be configured to accept the clients’ credentials (and vice-versa). Each security plugin has its own requirements re: credentials and their distribution.
MCollective servers must have agent plugins in order to do anything. Not every server needs the same set of agents, but clients need the agent DDL files for any agent from which they’ll trigger actions. You need to track what agents are in use.
If you divide your site into subcollectives for security or traffic reduction, you must globally configure the list of collectives and determine which business rules are assigned to specific nodes.
Servers and clients need to know which collectives to which they should subscribe and send requests, and their expectations must be aligned. (If you send requests on a subcollective no one else knows about, you won’t get anything interesting back.)
The middleware needs to know about them as well, since subcollectives are implemented in the connector plugin. See the configuration help for your specific middleware — either limit certain users from accessing some collectives, or prevent certain traffic from crossing inter-datacenter connections. You must configure these restrictions in the middleware rather than in MCollective.
If you are using an authorization plugin like ActionPolicy, you’ll need to configure its policies appropriately on every server. The rules for the policies must match the unique identities of the clients that will be sending requests, so the policies will be tied to your central knowledge of who and what the clients are.
With the ActionPolicy plugin, all policy files can safely be distributed to all servers, since each one defines which servers its rules apply to based on facts and other metadata.