Configure Tibco EMS JMS Transport Scenario for WSO2 API Manager with WSO2 ESB

This post describes how to configure WSO2 APIM 2.1.0 as a JMS Producer and gets a response back as a complete JMS story, using Tibco EMS and WSO2 ESB 5.0.0.

• WSO2 APIM hosts the API, that a client (i.e. cURL) would invoke.
• Tibco EMS acts as the JMS server
• WSO2 APIM 2.1.0 acts as a JMS Producer and once the API in API Manager is invoked by a client, it sends a JMS message to a JMS Queue (in Tibco EMS). We will call this JMS queue as 'Sender Queue- SMSStore'.  
• WSO2 ESB 5.0.0 act as the JMS consumer when subscribed and listening to Sender JMS queue.
• WSO2 ESB hosts a proxy service which routes the message to a backend service and send the response from backend service back to a JMS reciever queue.
• WSO2 ESB also acts as JMS a producer when sending back the response recieved from Backend service to a destination JMS queue.
• The backend service we use is a sample service deployed in WSO2 ESB (SimpleStockQuoteService) and it is deployed in the sample Axis2Server embeded within WSO2 ESB.

                                          Figure: Design and Message flow of the setup

Configure and setup APIM

1) Configure JMSSender  in <APIM_HOME>/repository/conf/axis2.xml

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

<?xml version="1.0" encoding="UTF-8"?> <transportSender name="jms" class="org.apache.axis2.transport.jms.JMSSender"> <parameter locked="false" name="QueueConnectionFactoryAPIM"> <parameter locked="false" name="java.naming.factory.initial">com.tibco.tibjms.naming.TibjmsInitialContextFactory</parameter> <parameter name="java.naming.provider.url">tcp://tibco.server.host.one:7222,tcp://tibco.server.host.two:7222</parameter> <parameter locked="false" name="transport.jms.ConnectionFactoryJNDIName">QueueConnectionFactoryAPIM</parameter> <parameter locked="false" name="transport.jms.JMSSpecVersion">1.0.2b</parameter> <parameter name="transport.jms.MaxJMSConnections">5</parameter> <!-- By default, Axis2 spawns a new thread to handle each outgoing message. To change this behavior, you need to remove the ClientApiNonBlocking property from the message.Removal of this property can be vital when queuing transports like JMS are involved. --> <property action="remove" name="ClientApiNonBlocking" scope="axis2" /> <parameter locked="false" name="transport.jms.ConnectionFactoryType">queue</parameter> <parameter name="transport.jms.DefaultReplyDestinationType" locked="true">queue</parameter> <parameter name="transport.jms.DestinationType" locked="true">queue</parameter> <parameter locked="false" name="transport.jms.UserName">apimuser</parameter> <parameter locked="false" name="transport.jms.Password">12345</parameter> <parameter locked="false" name="transport.jms.CacheLevel">connection</parameter> </parameter> </transportSender>

2) Copy below Tibco JMS client related jars into <APIM_HOME>/repository/components/extensions/ directory

1. jms-2.0.jar
2. tibemsd_sec.jar
3. tibjms.jar
4. tibjmsadmin.jar
5. tibjmsapps.jar
6. tibjmsufo.jar
7. tibrvjms.jar

3) Start the APIM server and create an API, Publish and subscribe to it with an Application. When creating the API, the endpoint of the API should be given as a JMS endpoint which actually points to the JMS queue (i.e. SMSStore), we will be creating later.

JMS endpoint :

"jms:/SMSStore?transport.jms.ConnectionFactory=QueueConnectionFactoryAPIM&transport.jms.ReplyDestination=SMSReceiveNotificationStore"

Note the below properties given in that endpoint address.

• (JMSQueue name): SMSStore D
• Direct endpoint JMS queue of the JMS message. It recieves the JMS messages.
• transport.jms.ConnectionFactory=QueueConnectionFactoryAPIM
• Queue ConnectionFactory which is used to create a QueueConnection between API Manager and Tibco EMS server.
• transport.jms.ReplyDestination=SMSReceiveNotificationStore
• JMS Queue, which recieves the response related to this request

Below I have mentioned a section of synapse API file created. ( related API resource that has our 
JMS endpoint )

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28

<?xml version="1.0" encoding="UTF-8"?> <resource methods="POST" url-mapping="/b" faultSequence="fault"> <inSequence> <property name="api.ut.backendRequestTime" expression="get-property('SYSTEM_TIME')" /> <filter source="$ctx:AM_KEY_TYPE" regex="PRODUCTION"> <then> <send> <endpoint name="admin--test_APIproductionEndpoint_1"> <http uri-template="jms:/SMSStore?transport.jms.ConnectionFactory=QueueConnectionFactoryAPIM&amp;transport.jms.ReplyDestination=SMSReceiveNotificationStore"> <timeout> <duration>60000</duration> <responseAction>fault</responseAction> </timeout> </http> <property name="ENDPOINT_ADDRESS" value="jms:/SMSStore?transport.jms.ConnectionFactory=QueueConnectionFactoryAPIM&amp;transport.jms.ReplyDestination=SMSReceiveNotificationStore" /> </endpoint> </send> </then> <else> <sequence key="_sandbox_key_error_" /> </else> </filter> </inSequence> <outSequence> <class name="org.wso2.carbon.apimgt.gateway.handlers.analytics.APIMgtResponseHandler" /> <send /> </outSequence> </resource>

Configure and setup ESB

1) Configure JMSListener and JMSSender in ESB - axis2.xml

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27

<transportReceiver name="jms" class="org.apache.axis2.transport.jms.JMSListener"> <parameter locked="false" name="QueueConnectionFactoryESB"> <parameter locked="false" name="java.naming.factory.initial">com.tibco.tibjms.naming.TibjmsInitialContextFactory</parameter> <parameter name="java.naming.provider.url">tcp://tibco.server.host.one:7222,tcp://tibco.server.host.two:7222</parameter> <parameter locked="false" name="transport.jms.ConnectionFactoryJNDIName">QueueConnectionFactoryESB</parameter> <parameter locked="false" name="transport.jms.JMSSpecVersion">1.0.2b</parameter> <parameter locked="false" name="transport.jms.ConnectionFactoryType">queue</parameter> <parameter locked="false" name="transport.jms.UserName">esbuser</parameter> <parameter locked="false" name="transport.jms.Password">12345</parameter> <parameter name="transport.jms.MaxJMSConnections">5</parameter> </parameter> </transportReceiver> <transportSender name="jms" class="org.apache.axis2.transport.jms.JMSSender"> <parameter locked="false" name="QueueConnectionFactoryESB"> <parameter locked="false" name="java.naming.factory.initial">com.tibco.tibjms.naming.TibjmsInitialContextFactory</parameter> <parameter name="java.naming.provider.url">tcp://tibco.server.host.one:7222,tcp://tibco.server.host.two:7222</parameter> <parameter locked="false" name="transport.jms.ConnectionFactoryJNDIName">QueueConnectionFactoryESB</parameter> <parameter locked="false" name="transport.jms.JMSSpecVersion">1.0.2b</parameter> <parameter locked="false" name="transport.jms.ConnectionFactoryType">queue</parameter> <parameter name="transport.jms.DefaultReplyDestinationType" locked="true">queue</parameter> <parameter name="transport.jms.DestinationType" locked="true">queue</parameter> <parameter locked="false" name="transport.jms.UserName">esbuser</parameter> <parameter locked="false" name="transport.jms.Password">12345</parameter> <parameter name="transport.jms.MaxJMSConnections">5</parameter> <parameter locked="false" name="transport.jms.CacheLevel">connection</parameter> </parameter> </transportSender>

Above are all the configurations required for this setup.

2) Other than that, copy below Tibco JMS client related jars into <ESB_HOME>/repository/components/extensions/ directory

• jms-2.0.jar
• tibemsd_sec.jar
• tibjms.jar
• tibjmsadmin.jar
• tibjmsapps.jar
• tibjmsufo.jar
• tibrvjms.jar

You can get them from the tibco installation directory.

i.e. /home/samithac/tibco/ems/8.4/lib

3) Deploy the Proxy service required in ESB. For that copy the below SMSForwardProxy.xml into <ESB_HOME>/repository/deployment/server/synapse-configs/default/proxy-services

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26

<?xml version="1.0" encoding="UTF-8"?> <proxy xmlns="http://ws.apache.org/ns/synapse" name="SMSForwardProxy" transports="jms" startOnLoad="true"> <description /> <target> <inSequence> <send> <endpoint> <address uri="http://localhost:9000/services/SimpleStockQuoteService" /> </endpoint> </send> </inSequence> <outSequence> <send /> </outSequence> </target> <parameter name="transport.jms.DestinationType">queue</parameter> <!-- listnening to this queue--> <parameter name="transport.jms.Destination">SMSStore</parameter> <parameter name="transport.jms.ContentType"> <rules xmlns=""> <jmsProperty>contentType</jmsProperty> <default>text/xml</default> </rules> </parameter> <parameter name="transport.jms.ConnectionFactory">QueueConnectionFactoryESB</parameter> </proxy>

I will post another blog post to describe how wso2 ESB Proxy works..be patient :-)

4) Deploy sample backend service (SimpleStockQuoteService) in to the Axis2 server. Open a command prompt (or a shell in Linux) and go to the required sample folder.  <ESB_HOME>/samples/axis2Server/src/SecureStockQuoteService . Then give the 'ant' command to build the sample and deploy.


                                                                                                                                                                            
5) Then start the axis2server within WSO2 ESB. For that, go o to <ESB_HOME>/samples/axis2Server/ directory and give run the axis2server.sh script to start the server.




Configure and setup Tibco EMS JMS server




1) Go to the tibco installation directory's bin directory and start the Server using below command.

./tibemsd64 -config ~/TIBCO_HOME/tibco/cfgmgmt/ems/data/tibemsd.conf




This startup command will load the configurations from ~/TIBCO_HOME/tibco/cfgmgmt/ems/data/tibemsd.conf







You can use the  TIBCO Enterprise Message Service Administration Tool to manage/view the connections, factories, etc. You can start it with ./tibemsadmin64 command.

2) Create 2 queues in JMS server 

I have created two queues with below names.

• SMSStore - Queue into which the APIM send the JMS message. ESB server also consumes JMS messages from this queue.
• SMSReceiveNotificationStore - Queue into which the ESB sends the response JMS message.

Sample command:

create queue SMSReceiveNotificationStore


3) Create 2 ConnectionFactories in JMS server


I have below two JMS connection factories been created already.

• QueueConnectionFactoryAPIM
• QueueConnectionFactoryESB

Sample command:

create factory QueueConnectionFactoryAPIM queue url=tcp://localhost:7222 reconnect_attempt_delay=100000 reconnect_attempt_count=3




You can see the Connection Factories been created in

/home/samithac/TIBCO_HOME/tibco/cfgmgmt/ems/data/factories.conf file as below. You can create the Connection Factories by manually adding into the above file too.

[QueueConnectionFactoryESB]

  type                     = queue

  url                      = tcp://tibco.server.host.one:7222

  connect_attempt_count = 3

  connect_attempt_delay = 15000

  connect_attempt_timeout = 10000

  reconnect_attempt_count = 1

  reconnect_attempt_delay = 1

  reconnect_attempt_timeout = 5000

[QueueConnectionFactoryAPIM]

  type                     = queue

  url                      = tcp://tibco.server.host.one:7222

  connect_attempt_count = 3

  connect_attempt_delay = 15000

  connect_attempt_timeout = 10000

  reconnect_attempt_count = 1

  reconnect_attempt_delay = 1

  reconnect_attempt_timeout = 5000

Ok. Now you are ready. Tou can invoke the API and get a response back. Below is how I invokded the API via cURL client and got the expected response back. The payload used is saved in a xml file named payload.xml and placed at the directory where the curl command is given.

1 2 3 4 5 6 7 8 9 10 11 12

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ser="http://services.samples" xmlns:xsd="http://services.samples/xsd"> <soapenv:Header/> <soapenv:Body> <ser:getQuote> <!--Optional:--> <ser:request> <!--Optional:--> <xsd:symbol>message</xsd:symbol> </ser:request> </ser:getQuote> </soapenv:Body> </soapenv:Envelope>

Sample cURL command:

curl -X POST --header 'Content-Type: application/xml' --header 'Accept: application/xml' --header 'Authorization: Bearer 9b17298d-6404-338e-9036-271bb7a239f3' -d @payload.xml 'https://10.100.7.124:8243/test/1.0.0/b' -k

That's it. Cheers...!

References:

http://blog.samisa.org/2014/01/jms-usecases-tutorial-with-wso2-esb.html
https://docs.wso2.com/display/ESB500/ESB+as+Both+a+JMS+Producer+and+Consumer

Configuring SSL Termination with WSO2 API Manager

When you are setting up WSO2 API manager fronted with a load balancer, you have the option of terminating SSL for HTTPS requests. So the load balancer will be decrypting incoming HTTPS messages and forwarding them to the Carbon servers as HTTP. So basically the APIM should be working with HTTP requests, after surpassing the load balancer. This is useful when you want to reduce the load on your Carbon servers due to encryption. To achieve this, the load balancer should be configured with TLS termination and the Tomcat RemoteIpValve should be enabled for Carbon servers.

I am going to describe the steps you have to follow for your exact requirement, from the beginning so that you can follow.

In these steps, note the below facts.

• I am using “localhost” as the hostname.
• Proxy url context path for publisher is “/apimanager/publisher”
  So the publisher url can be used through the LB is https://localhost/apimanager/publisher/
• Proxy url context path for store is “/apimanager/store”
  So the store url can be used through the LB is https://localhost/apimanager/store
• Token generatoin url is https://localhost/token
  

1. Configuring Load balancer

 

I am using nginx as the load balancer. As we are not competent with the F5 which you use as the load balancer, we will not be able to provide guidance/scripts to configure F5. I am providing the following guide with Nginx so that you can have the basic understanding on what has to be done via the load balancer for this task. You may use this knowledge to configure F5.
Configure the /etc/nginx/sites-enabled/default file as below.

server {
       listen 443;
       ssl on;
       ssl_certificate /etc/nginx/ssl/nginx.crt;
       ssl_certificate_key /etc/nginx/ssl/nginx.key;
       location /apimanager/carbon {
           index index.html;
           proxy_set_header X-Forwarded-Host $host;
           proxy_set_header X-Forwarded-Server $host;
           proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
           proxy_set_header Host $host;
           proxy_set_header X-Real-IP $remote_addr;
           proxy_set_header X-Forwarded-Proto $scheme;
           proxy_pass http://localhost:9763/carbon;
           proxy_redirect  http://localhost:9763/carbon  https://localhost/apimanager/carbon;
           proxy_cookie_path / /apimanager/carbon/;
       }
 
       location ~ ^/apimanager/store/(.*)registry/resource/_system/governance/apimgt/applicationdata/icons/(.*)$ {
           index index.html;
           proxy_set_header X-Forwarded-Host $host;
           proxy_set_header X-Forwarded-Server $host;
           proxy_set_header Host $host;
           proxy_set_header X-Real-IP $remote_addr;
           proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
           proxy_set_header X-Forwarded-Proto $scheme;
               proxy_pass http://localhost:9763/$1registry/resource/_system/governance/apimgt/applicationdata/icons/$2;
       }
 
 
       location ~ ^/apimanager/publisher/(.*)registry/resource/_system/governance/apimgt/applicationdata/icons/(.*)$ {
           index index.html;
           proxy_set_header X-Forwarded-Host $host;
           proxy_set_header X-Forwarded-Server $host;
       proxy_set_header Host $host;
           proxy_set_header X-Real-IP $remote_addr;
           proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
           proxy_set_header X-Forwarded-Proto $scheme;
           proxy_pass http://localhost:9763/$1registry/resource/_system/governance/apimgt/applicationdata/icons/$2;       
      }
 
       location /apimanager/publisher {
          index index.html;
          proxy_set_header X-Forwarded-Host $host;
          proxy_set_header X-Forwarded-Server $host;
         proxy_set_header Host $host;
          proxy_set_header X-Real-IP $remote_addr;
          proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
          proxy_set_header X-Forwarded-Proto $scheme;
          proxy_pass http://localhost:9763/publisher;
          proxy_redirect  http://localhost:9763/publisher  https://localhost/apimanager/publisher;
          proxy_cookie_path /publisher /apimanager/publisher;
      }
 
      location /apimanager/store {
          index index.html;
          proxy_set_header X-Forwarded-Host $host;
          proxy_set_header X-Forwarded-Server $host;
         proxy_set_header Host $host;
          proxy_set_header X-Real-IP $remote_addr;
          proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
          proxy_set_header X-Forwarded-Proto $scheme;
          proxy_pass http://localhost:9763/store;
          proxy_redirect http://localhost:9763/store https://localhost/apimanager/store;
          proxy_cookie_path /store /apimanager/store;
       }

       location / {
              proxy_pass http://localhost:8280;
       }
}

Certificate generation for nginx has to be done. Follow https://docs.wso2.com/display/AM210/Adding+a+Reverse+Proxy+Serve for it.
And then start nginx server.

Next file configurations are related to configuring WSO2 API Manager.

2. tomcat/catalina-server.xml file configuration 

 

Do the following configs in <CARBON_HOME>/repository/conf/tomcat/catalina-server.xml

a) Enabling RemoteIpValve for Carbon servers

Configure RemoteIPValve in <CARBON_HOME>/repository/conf/tomcat/catalina-server.xml as below.

<Valve className="org.apache.catalina.valves.RemoteIpValve" 

remoteIpHeader="X-Forwarded-For" protocolHeader="X-Forwarded-Proto" />

 b) Set proxy port and hostname

 <Connector protocol="org.apache.coyote.http11.Http11NioProtocol"
              port="9443"
             proxyPort="443"
               hostname="localhost"
              bindOnInit="false"
              sslProtocol="TLS"
---
--
/> 

3. carbon.xml configuration

Configure <APIM-HOME>/repository/conf/carbon.xml file as below.

• Uncomment following element, 

        <HttpAdminServices>*</HttpAdminServices>

• Set,  

        <EnableHTTPAdminConsole>true</EnableHTTPAdminConsole>

• Set hostname,

        <HostName>localhost</HostName>
        <MgtHostName>localhost</MgtHostName>

4. site.json files of web apps

a)

• Edit the <APIM_HOME>/repository/deployment/server/jaggeryapps/store/site/conf/site.json file with the context and request URL as shown below.
• This is done to configure the reverse proxy server for WSO2 API Store, so that you can route the requests that come to the store through a proxy server.

"reverseProxy" : {
        "enabled" : true, 
        "host" : "localhost", // If the reverse proxy does not have a domain name use the IP
        "context":"/apimanager/store",
        "regContext":"" // Use this only if a different path is used for the registry
    }

b)

• Edit the <APIM_HOME>/repository/deployment/server/jaggeryapps/publisher/site/conf/site.json file with the context and host as shown below.
• This is done to configure the reverse proxy server for WSO2 API Publisher, so that you can route the requests that come to the publisher through a proxy server. 

"reverseProxy" : {
        "enabled" : true, 
        "host" : "localhost",//If the reverse proxy does not have a domain name use the IP
        "context":"/apimanager/publisher",
        "regContext":"" // Use this only if a different path is used for the registry
    } 

5. Configuring api-manager.xml file.

• Change the value of KeyValidatorClientType to WSClient in the <APIM_HOME>/repository/conf/api-manager.xml file.
• You need to make this change when you change the value of the host, because requests that are made to the Key Manager will also start getting routed through the reverse proxy; therefore, this needs to be over HTTP instead of TCP, which is Thrifts underlying protocol.

        <KeyValidatorClientType>WSClient</KeyValidatorClientType>

• Change gateway endpoint urls displayed on store,

       <GatewayEndpoint>http://localhost,https://localhost</GatewayEndpoint>  

  
  Set Store URL to be linked and from publisher,
       <APIStore>
              <URL>https://localhost/apimanager/store</URL>
       ---
       </APIStore>
  
  This is it..!
  
  
  

WSO2 Puppet Deployment

WSO2 Products are accompanied with puppet modules which make your life easier when setting up and configuring a product as per the requirement/the deployment architecture. I am going to provide an introduction and guide on how to use these puppet modules for development or deployment purposes.

So if you are a developer and want to customize a WSO2 puppet module (to facilitate further flexibility or add more parameterized configurations), this post would be a good starter. 

And also if you are a user who directly want to setup/configure a puppet environment to deploy a certain enterprise deployment, you may read this.

WSO2 Puppet architecture was changed completely within last year and so now the puppet modules of each wso2 product are in separate git repositories as opposed to the old structure where all-were-in-one. The old WSO2 puppet-modules repository can be found here if you just want to have a lookup. That is now been deprecated and all the latest product related puppet scripts are written/been written under the new architecture, which I am going to describe here.

What is done by puppet...?

 

Before reading further let's clarify, what puppet does with respect to WSO2 products ? We have to understand this.

For a beginner into puppet, and for whom being ready to tackle with WSO2 puppet modules I may introduce puppet as below and this is very simple and premature introduction on what puppet does. (this concept could be common for any other puppet module too )

Following diagram (Figure 1) illustrate what is occurred simply when we use WSO2 APIM 2.1.0 puppet module to deploy and configure the product in production environment.

 

Figure 1

I guess you didn't understand this 100%. Don't worry. :-D .I am describing.

In the repository-which we call as WSO2 puppet module (for instance take wso2-apim-2.1.0 puppet module), there are configuration files acting as templates for each file that needs to be edited/configured in a product deployment. eg. axis2.xml, carbon.xml, master-datasources.xml.

The difference between an actual vanila product pack's config file and a related puppet template file is that the latter has been replaced with variables/parameters in order to change their values at runtime.

And a puppet module basically includes files (hiera files) with lists of values to be passed to each parameter/variable in each those config files. These values, which we call as hiera data are defined separately for each deployment pattern (or profile if available).

So when we "run" puppet, 3 basic steps are executed by puppet, as mentioned in the above figure.

1 - Apply the configuration data (of the required pattern), into the puppet template files.

2 - Replace the vanilla wso2am-2.1.0 product's configuration files with the modified template files of step 1.

3 - Copy the modified product pack, in step 2, into the production environment and start the product server.

Ok, now you know what we do with puppet, so shall we move in deeper. First we may clarify, the parts and particles of WSO2 puppet modules.

Organization of WSO2 Puppet repositories

If you are going to work with a certain WSO2 product (for a puppet deployment), you may have to deal with 3 functional components, which are found as git repositories.

1. The certain WSO2 product related repository
2. puppet-base repository
3. puppet-common repository

Both 2 and 3 are required for a puppet deployment of a WSO2 product.

1. The certain WSO2 product related repository

Each WSO2 product has a puppet-module repository. (i.e. puppet-apim, puppet-is, puppet-das, puppet-esb, puppet-iot, puppet-ei). Most of these has been released for latest product release ( as per the status by June 2017 ) and please find the puppet module repository list in here. These are consisted of puppet scripts that support multiple patterns of deployment and multiple profiles if available.

Let's take WSO2 API Manager puppet modules for instance. It consists of 3 puppet modules which are related to WSO2 APIM product. They are as below and the specif product related to each module is mentioned infront.

1. wso2am_runtime - WSO2 API Manager 2.1.0
2. wso2am_analytics - WSO2 APIM Analytics Server 2.1.0
3. wso2is_prepacked - Pre-packaged WSO2 Identity Server 5.3.0 (for IS  as  Key Manager APIM deployment)

And this wso2am_runtime module includes puppet scripts which facilitate deployment of APIM in 7 deployment patterns, with 5 APIM profiles.

2. puppet-base repository

WSO2 base puppet repository can be found in here. Puppet-base is also another "puppet module" according to the puppet perspective. This provides features for installing and configuring WSO2 products. On high level it does the following:

1. Install Java Runtime
2. Clean CARBON_HOME directory
3. Download and extract WSO2 product distribution
4. Apply Carbon Kernel and WSO2 product patches
5. Apply configuration data
6. Start WSO2 server as a service or in foreground

3. puppet-common repository

WSO2 Puppet Common repository provides files required for setting up a Puppet environment to deploy WSO2 products.

• manifests/site.pp: Puppet site manifest
• scripts/base.sh: Base bash script file which provides utility bash methods.
• setup.sh: The setup bash script for setting up a PUPPET_HOME environment for development work.
• vagrant A vagrant script for testing Puppet modules using VirtualBox.

Setting up a puppet environment

There are basically 2 approaches to setup a puppet environment.

1. Using vagrant and Orcle VirtualBox
2. Master agent environment
   

It is recommended to select the appropriate approach considering the requirement.

1. Using vagrant and Orcle VirtualBox

 

Vagrant can be used to setup the puppet development environment to easily test a WSO2 product's Puppet module.

In this approach, Vagrant is used to automate creation of a VirtualBox VM (Ubuntu 14.04) and deploy/install the WSO2 product using the WSO2 puppet modules.

This approach is very easier than Master-agent approach considering the convenience of setup. But this is less convenient in the case of debugging for errors as vagrant takes much time to up a WSO2 product with puppet as the process includes creating a Virtual Machine in Virtual Box too. If you are developing a WSO2 puppet module, from beginning, this is not the recommended approach. But if you are not a newbie to puppet, and so have a good expertise on how puppet modules works with WSO2 products, then you may use this approach (as u will make less errors).

And you cannot use this puppet environment to deploy and install a certain WSO2 product into an actual production environment. Because, this install the product into a VirtualBox Virtual Machine which is created automatically on the go.

For the steps to follow to use this approach follow the official WSO2 documentation Wikis in github here.

2. Master agent environment

 

  Master-agent environment can be used to deploy/install WSO2 products in actual production environments. And also if you are developing a puppet module from the beginning or doing major customizations to the existing puppet modules and your development task would take multiple days/weeks, it is better to follow this approach. Because this is convenient in the case of debugging, testing time for each run, re-running after customizations, etc. But this is bit cumbersome, to setup this master-agent environment as it takes much time and and also need multiple OS instances/computers.

To setup a master-agent puppet environment with WSO2 puppet modules, follow the steps in official WSO2 Documentation Wikis in github.


References:

https://github.com/wso2/puppet-base/blob/master/README.md
https://github.com/wso2/puppet-common/blob/master/README.md