MCollective or 'Marionette Collective' is a framework to distribute parallel commands to a cluster of computers. You can basicly compare it to remote execution except the framework is organized to work the commands in parallel. Via a simple plugin structure of ruby it is relatively easy to write your own commands.
Marionette Collective works on top of a message queue broker, you can pick different flavors for the broker but the most common adoption appears to be activemq. Other brokers such as rabbitmq are supported as well.
With MCollective there are basicly two configations 'server' and 'client', contrary to terminology, 'server.cfg' is used for the deamon service. In this configuration file you configure what queue on the broker the deamon connects to receive commands. In the 'server.cfg' you configure the queue on the broker to send the commands. So in short: server.cfg is for the command-line client, client.cfg is for the deamon process.
With MCollective it's possible to create a self-updating command for example just create a command that downloads new ruby files from an ftp server. After installing new ruby files you should restart the service to make it go into effect. The problem with self-updating services however is that technically it's possible to cause an update which due to improper testing causes the deamon not to continue loading. This problem is leviated a little bit due to the lazy-loading nature of interprented languages like ruby; the problem still exists however.
To leviate this form of issue the general idea in devops practices is to increase the coverage with a secondair update stratergy. For example via puppet or via saltstack. This is likely one of the reasons puppet deciced to bundle their software with MCollective.
Marionette Collective works on top of a message queue broker, you can pick different flavors for the broker but the most common adoption appears to be activemq. Other brokers such as rabbitmq are supported as well.
With MCollective there are basicly two configations 'server' and 'client', contrary to terminology, 'server.cfg' is used for the deamon service. In this configuration file you configure what queue on the broker the deamon connects to receive commands. In the 'server.cfg' you configure the queue on the broker to send the commands. So in short: server.cfg is for the command-line client, client.cfg is for the deamon process.
With MCollective it's possible to create a self-updating command for example just create a command that downloads new ruby files from an ftp server. After installing new ruby files you should restart the service to make it go into effect. The problem with self-updating services however is that technically it's possible to cause an update which due to improper testing causes the deamon not to continue loading. This problem is leviated a little bit due to the lazy-loading nature of interprented languages like ruby; the problem still exists however.
To leviate this form of issue the general idea in devops practices is to increase the coverage with a secondair update stratergy. For example via puppet or via saltstack. This is likely one of the reasons puppet deciced to bundle their software with MCollective.
Comments
Post a Comment