Creating a Puppet Module for a WSO2 Product

A Puppet module should have following sections:

• Puppet module template
• Hiera data files

Create the Module

A Puppet module includes the following components.

• files - Contains any static files that should be copied over to the location being configured by Puppet. This serves as a file server for the Puppet Agent.

• manifests - Contains the business logic of the Puppet module. The Puppet manifests contain blocks of dependent instructions, after the execution of which, should result in the intended state.

• templates - Contains the template files that are combined with a set of values and applied to in the target environment. These files are suffixed by .erb file extension.

Tips on Creating a Puppet Module Structure

• Use the same structure used in other puppet modules. (eg: wso2am)

• Module Components follow a specific structure in wso2/puppet-modules.

  • files: Contains patches and configs folders. Patches folder is used to copy any patches and configs is used to copy any files such as MySQL Connector. Use the relative file path from the Carbon home. Product zip file should be placed under files section.

  • manifests: Contains only init.pp file. Puppet module class should inherit from wso2base. This can follow the same structure in other modules. Additionally init.pp should have the product specific Hiera lookups. If your template has product specific puppet variable, it should be mentioned in the init.pp.

  • templates: Contains the puppet template for the product. Template should have only the puppet variables and it should not have any Hiera lookups within the template.

Create the Hiera Configuration Data Set

The Hiera data for the templates that were added to the Puppet module earlier should now be created. The YAML files map to the product profiles that are available for each product. For example, for WSO2 ESB, there are three profiles, default, manager, and worker. These profiles are mapped to default.yaml, manager.yaml, and worker.yaml files respectively.

The hierarchy of the Hiera data set should be similar to the following.

wso2/puppet-modules
├── hieradata
│   └── dev
│       └── wso2
│           └── wso2product
│               └── product_version
│                   └── platform
│                       ├── default.yaml
│                       ├── profile1.yaml
│                       └── profile2.yaml

Tips on Creating Hiera Configuration Data Files

• Based on the product profiles, Hiera data files should be created
• Use wso2 as the namespace when defining keys in the Hiera data files
• Make sure you have following values in the Hiera data files.
  • wso2::pack_filename : The product distribution file name, ex: wso2esb-4.9.0.zip.
  • wso2::pack_extracted_dir : The target directory name to extract the product, ex: wso2esb-4.9.0
  • wso2::hostname : The hostname to be used in the instance
  • wso2::service_name : Service name of the product
  • wso2::file_list : Any product specific file that needs to be copied should be listed down here.
  • wso2::template_list : All the product specific templates should be listed down here.

wso2::template_list :
 - repository/conf/security/cipher-text.properties
 - repository/conf/security/cipher-tool.properties
 - bin/ciphertool.sh
 - password-tm

wso2::file_list :
 - repository/components/lib/mysql-connector-java-5.1.36-bin.jar

• Following is the Hiera value for WSO2 ESB default profile. You can use it as a starting point by adjusting the product name (wso2esb).

---
classes:
  - wso2esb
wso2::pack_filename: "%{::product_name}-%{::product_version}.zip"
wso2::pack_extracted_dir: "%{::product_name}-%{::product_version}"

wso2::service_name: wso2esb
wso2::hostname : esb.wso2.com