Configurator
Product configurations can be automated with orchestration management systems such as Puppet, Chef, Salt, Ansible, etc. Most of these orchestration systems provide their own templating engine for templating configuration files. The problem with this model is that for each orchestration system a separate set of templates need to be created for the same product. Switching between different orchestration systems & maintaining different sets of templates files are very costly. Furthermore, instance configuration will have complex requirements. In the case of a Cartridge instance, there are numerous run-time factors that you need to take into account for the correct configuration to take place. Some of these factors include clustering and database information, the role of the Cartridge type in the clustering context and even the role of the Cartridge on the product specific distributed setup (such as that of WSO2 API Manager).
WSO2 Configurator solves these problems by implementing a generic templating solution, which can work with any orchestration system, and also tackle the cumbersome task of configuring products and instances that have complex requirements. Thereby, you can use the Configurator to seamlessly automate the configuration process that needs to be carried out when configuring Private PaaS and its cartridges.Â
WSO2 Configurator is a Python module written using the Jinja2 template engine, which can configure a product using a set of key/value pairs. As shown in the above diagram configuration parameters can be either provided by using a set of environment variables or using the module.ini
file inside the template module. The template module includes the template files, any other files that need to be copied to the product distribution, such as patches, and the module.ini file.
WSO2 Private PaaS Cartridges releases template modules for all the WSO2 products.
Template Module
The Configurator operates on a set of configuration templates, which are referred to as a Template Module
. A Template Module should be of the following folder structure and should contain the files and templates, which are needed to configure the specific Cartridge.
├── files
├── templates
└── module.ini
files
The files
 folder contains the static files, which do not require any template processing. For example, mysql-connector-java-5.1.36.jar
 file should go inside the files
 folder.Â
templates
The templates
folder contains the configurable template files. For example, if clustering can be configured in a particular template module for a Carbon product, the axis2.xml
file should be included in the templates folder as a templated file, axis2.xml.template
. The template file content for the clustering related area can look as follows:
<clustering class="org.wso2.carbon.core.clustering.hazelcast.HazelcastClusteringAgent" enable="{{ CONFIG_PARAM_CLUSTERING }}"> <parameter name="membershipScheme">{{CONFIG_PARAM_MEMBERSHIP_SCHEME}}</parameter> <parameter name="domain">{{CONFIG_PARAM_DOMAIN}}</parameter> <parameter name="localMemberHost">{{CONFIG_PARAM_LOCAL_MEMBER_HOST}}</parameter> <parameter name="localMemberPort">{{CONFIG_PARAM_LOCAL_MEMBER_PORT}}</parameter> <parameter name="properties"> <property name="backendServerURL" value="https://${hostName}:${httpsPort}/services/"/> <property name="mgtConsoleURL" value="https://${hostName}:${httpsPort}/"/> {% if CONFIG_PARAM_SUB_DOMAIN == 'mgt' %} {% if CONFIG_PARAM_PT_HTTP_PROXY_PORT is defined -%} <property name="port.mapping.80" value="{{CONFIG_PARAM_PT_HTTP_PROXY_PORT}}"/> {% else -%} <property name="port.mapping.80" value="9763"/> {% endif -%} {% if CONFIG_PARAM_PT_HTTPS_PROXY_PORT is defined -%} <property name="port.mapping.443" value="{{CONFIG_PARAM_PT_HTTPS_PROXY_PORT}}"/> {% else -%} <property name="port.mapping.443" value="9443"/> {% endif -%} <property name="subDomain" value="mgt"/> {% endif %} <!-- Worker Setup--> {% if CONFIG_PARAM_SUB_DOMAIN == 'worker' %} <property name="subDomain" value="worker"/> {% endif %} </parameter> <members> {% for key, value in CONFIG_PARAM_WKA_MEMBERS.iteritems() -%} <member> <hostName>{{ key }}</hostName> <port>{{ value }}</port> </member> {% endfor -%} </members>
The Configurator uses the following templating language:Â Jinja Templating
module.ini
The module.ini
file contains the configurable options for the specific template module. For example, for the above mentioned clustering enabled axis2.xml.template
file, the following can be the likely entries of the module.ini
file.
[SETTINGS] READ_FROM_ENVIRONMENT=true CARBON_HOME=/opt/wso2am-1.9.1 [PARAMS] CONFIG_PARAM_CLUSTERING=true CONFIG_PARAM_MEMBERSHIP_SCHEME=wka CONFIG_PARAM_DOMAIN=wso2.carbon.domain CONFIG_PARAM_LOCAL_MEMBER_HOST=127.0.0.1 CONFIG_PARAM_LOCAL_MEMBER_PORT=4000 CONFIG_PARAM_WKA_MEMBERS=[127.0.0.1:4000] CONFIG_PARAM_PORT_OFFSET=0 CONFIG_PARAM_PROFILE=Default
Â
READ_FROM_ENVIRONMENT
If READ_FROM_ENVIRONMENT
is set to true
, then the Configurator will override any values specified in the module.ini
file with values from the environment variables.Â
CARBON_HOME
CARBON_HOME
is the path to the product, which has to be configured using the specified templates.Â
Running the Configurator
The Configurator is hosted on the Private PaaS Cartridge Repository. When running the configurator you have to point to the location of the template module. It will look for the module.ini
file, read the configuration values, process the templates inside templates
folder, and copy the processed templates and the files inside files
folder to the CARBON_HOME
. For details steps on running the configurator, see Running the Configurator with a Template Module.