This documentation is for WSO2 Puppet Modules version 2.0.0. View documentation for the latest release.
We have moved WSO2 Puppet Modules to separate product specific repositories, and as a result the puppet-modules repository, which this documentation is based on has been deprecated.
A new puppet-common repository has been introduced. Please find the new repository list here.
Masterless - puppet apply - WSO2 Puppet Modules 2.0.0 - WSO2 Documentation
Skip to end of metadata
Go to start of metadata

The Puppet apply approach is recommended when testing and adjusting to a proper Puppet strategy. This strategy uses the local Puppet manifests and data and does not communicate with an outside server to retrieve any of the Puppet artifacts, such as templates, defined types, and files. The Puppet Vagrant setup, shipped with WSO2 Puppet Modules uses puppet apply  to test a given Puppet module. 

Configuring the Puppet working directory

In the Master-Agent scenario, the Puppet agent retrieves the necessary Puppet logic and artifacts from the Puppet Master. In the local Puppet apply scenario, such configurations have to be manually setup. 


Step 1- Copy the distribution

Download the WSO2 Puppet Modules 2.0.0 distribution ZIP file and extract it into a location of your choice. This location is referred to as PUPPET_HOME hereafter.

unzip -d /etc/puppet


Step 2 - Add the required configurations

  • Default Profile
    All modules that are shipped with WSO2 Puppet Modules, support the process of setting up each product as a standalone instance and run with the default profile out-of-the-box. There are no additional configurations needed.
  • Distributed Profiles
    You need to carryout the minimal configurations, which include datasources, registry mounts, and deployment synchronization, for the distributed profiles to work. In WSO2 Puppet Modules, configurations that are common to all the profiles are included in the default.yaml file. Uncomment the latter mentioned configurations, and enter the deployment specific data such as database server IP addresses, database credentials, and SVN server information. Profile specific configurations are included in the <profile>.yaml files, which override the default values that are available in the default.yaml file.

In addition to configuration changes, configure external resources, such as database servers, and SVN servers, separately.

  • In addition to the above, an important configuration that may often change is the installation location, which is specified in the hieradata/dev/wso2/common.yaml file as install_dir. By default,  install_dir  points to /mnt/<ip_address>. You can either change this value in the hieradata/dev/wso2/common.yaml file itself, or override the value in the <product>/<version>/default/default.yaml file. 
wso2::install_dir: "/mnt/%{::ipaddress}"


Step 3 - Copy the packs

Follow the instructions below to copy the required packs: 

  1. Copy the Oracle JDK distribution to the <PUPPET_HOME>/modules/wso2base/files directory.
  2. Copy the product distribution pack to the <PUPPET_HOME>/modules/<product>/files directory.   

    The above two pack are the minimal minimum external files that are required to configure a standalone instance.
  3. Copy any other files (e.g.,  third-party libraries, pluggable configurers, etc.) to the configs folder of the relevant product module.
    For example, if you need the MySQL Connector for Java, copy it into the <PUPPET_HOME>/modules/<product>/files/configs/repository/components/lib directory.
  4. Copy the patch folders (patchxxxx) into the <PUPPET_HOME>/modules/<product>/files/patches/repository/components/patches directory.
  5. Copy any other files that are within the patch into the relevant location in the corresponding folder structure inside the <CARBON_HOME> directory.
    For example, if any database scripts are distributed with a patch, then you need to copy the contents of the dbscripts folder into the <PUPPET_HOME>/modules/<product>/files/patches/dbscripts directory. 

Step 4 - Run Puppet

  1. Set Custom Facts.
    WSO2 Puppet Modules make use of several custom Puppet Facts to assign configurations to specific products, versions, platforms, and profiles. These custom Facts need to be in the instance that is executing Puppet, and set as environment variables with the FACTER_ prefix.
    For example, set the following Facts to configure the WSO2 API Manager 1.10.0 default profile.

    export FACTER_product_name=wso2am
    export FACTER_product_version=1.10.0
    export FACTER_product_profile=default
    export FACTER_environment=dev
    export FACTER_platform=default
  2. Execute Puppet Apply.
    Navigate to the <PUPPET_HOME> directory and execute the following command using the root permission to run Puppet.
    Example: WSO2 API Manager
puppet apply -e "include wso2am" --modulepath=$(pwd)/modules --hiera_config=$(pwd)/hiera.yaml $(pwd)/manifests/site.pp
  • No labels