Core components to configure VMs
In this section the components involved in the automatic configuration of virtual machines are briefly described.
In the Open-DAI project, Puppet is exploited as configuration management system that allows you to define the state of the IT infrastructure, then automatically enforces the correct state. As explained in its documentation, Puppet uses an Agent/Master (client/server) architecture for configuring systems in which managed nodes run the Puppet Agent application, usually as a background service, and a server run the Puppet Master application. Periodically, Puppet Agent sends facts (a collection of information about its system) to the Puppet Master and requests a catalog. The Master compiles and returns that node’s catalog, using several sources of information it has access to. Once it receives a catalog, Puppet Agent applies it by checking each resource the catalog describes. If it finds any resources that are not in their desired state, it makes any changes necessary to correct them. After applying the catalog, the Agent submits a report to the Puppet Master.
The approach used in the Open-DAI project is the following:
- use some standard exixting modules from the community or develop some basic generic modules for the components that the project uses.
These last modules have been published in GitHub and are summarized in the list below:
- the project than created wrapper modules to configure the set of software components as needed by the Open-DAI platform, also these puppet modules are published in GitHub:
Base (the main module that all the Nodes are based on that is the module able to recognize the role passed to the cloud environment and understand which module apply to the node)
odaijbossmasterbb is the module that install the master node of the JBoss cluster (installing also Geoserver, TEIID)
odaijbossslavebb is the mosule that install the slave node of the JBoss cluster
odaiweb is the module that install the Apache node with the mod_cluster for balancing the JBoss cluster
odaiapiman is the module that set up the WSO2 API Manager, wired towards the BAM server
odaibam is the module that set up the Business Activity Monitor
The architecture of MCollective is based around three main components: servers, clients, and the middleware. An MCollective server (often just called a “node”) is a computer which can be controlled via MCollective. An MCollective client can send requests to any number of servers, using a security plugin to encode and sign the request and a connector plugin to publish it. It can also receive replies from servers, and format the response data for a user or some other system. MCollective clients and servers don’t communicate directly: they expect to be connected to some middleware system that knows how to route messages. They then publish messages to the middleware, and subscribe to messages they are interested in. The connector and middleware handle three main kinds of messages:
- Broadcast requests (client-to-server)
- Directed requests (client-to-server)
- Replies (server-to-client)