Skip to main content

How to deploy your WSO2 server in 1 minute with puppet


First I want to tell you that this is not a 1 minute tutorial as the “Sams Teach Yourself” series. This is about deploying your next WSO2 server (first server you deploy after following this tutorial) in 1 minute . Enough talking and let me take you straight in to the task.

The concepts and the configurations I am describing here can be used in any kind of scalable deployment with WSO2 products. Below is a diagram of a system which we normally see in an enterprise integration project.




Here you can see there are 3 set of systems and a number of WSO2 servers in the entire deployment. The generic approach to this kind of deployment is to first do the end to end implementation within the development setup and then move these configurations in to QA and Production systems. When you are installing your QA or production environment, you need to make sure all the things that done within the development setup are there in the production setup in a seamless manner.

You don't need to copy your development setup in to each and every server and configure them manually. That will cause a lot of issues that are harder to find when the system is up and running. Best way is to automate the process of deployment with the help of puppet. Before continuing further, you need understand what puppet is and how to install puppet in your environment. You can find enough information on the below links.



Once you have installed puppet master and puppet agent in your servers, now you are ready to make it happen. (1 minute thing)

Let's say you have to install WSO2 ESB in 10 servers of your Dev, QA and Production setup. You need to follow the below mentioned tasks to install your last 9 servers in less than 9 minutes.

1. Define your software and installation related information in the puppet master node.
2. Describe the nodes in which you are going to install WSO2 ESB in the site.pp puppet script in the puppet master node.
3. Run the puppet agent from the agent node where you need to install the WSO2 ESB.
4. Check the file system and the log to see your WSO2 ESB is up and running.


Define your software and installation related information in the puppet master node.

This is the task which you need to do carefully once and then you can sit back with ease when your boss ask for the expansion.

  • Download the puppet scripts for WSO2 ESB from the link below.

  • Extract these files in to a convenient location. Once you extracted the esb directory ( inside 4.8.0/esb ), you can find a set of files which is similar to the following structure.


You can see at the top level there are 3 directories. These are the important directories we need to properly configure.

/files directory

configs/ - Directory for placing your synapse level configurations of the WSO2 ESB server

patches/ - Patch files you need to apply for WSO2 ESB server

/manifests directory

params.pp – Define the parameters like WSO2 ESB zip file location, user database details, installation directories, etc …

init.pp – main class file which will execute when running the puppet agent. This will trigger all the other stages of the puppet deployment. Name of this class should match with the module name (esb)

clean.pp – This puppet script will clean up the existing installation (if there is any) and remove the files from the server. (Uninstalling ESB)

initialize.pp – Do the initialization of ESB installation by copying and extracting the zip files which contains the WSO2 ESB package.

deploy.pp – Deploy the configurations and patches from the files directory in to the extracted ESB directory

push_templates.pp – Push all the templates (static configuration files like cabon.xml, axis2.xml, datasources.xml, etc) in to the ESB directory. Replace the default ones with these configured ones.

start.pp - Finally, start the WSO2 ESB with the newly configured server.

/templates directory

Inside this directory, you can find familiar configuration files for the WSO2 ESB. These files are the same as the default configurations which comes with WSO2 ESB but parameterized to change the configurations according to your environment through the puppet script. For example, If you check in the carbon.xml.erb file, you can find this statement.

<Offset><%= @offset %></Offset>

Here the Offset value of the carbon server is parameterized such that we can change this through the puppet script. Likewise, you can find many files which are parameterized to make them configure from the puppet scripts.
OK. Now you know what are the contents of the puppet scripts which you have downloaded from the wso2 puppet repository and what needs to be changed. Go through the puppet scripts ( they are not large) and change the few parameters according to your environment. For example, if you have a file server where you keep all the wso2 product zip files (This is the recommended way, rather than keeping them in a server like puppet master). Let's say the URL of the file server is


You have all the zip archives of WSO2 products inside this location. Now you have to open the params.pp file and change


Likewise carefully change the parameters of this file according to your environment.

Once you are done with the required changes, copy this esb folder in to puppet master server inside /etc/puppet/modules directory.


Describe the nodes in which you are going to install WSO2 ESB

Now you are done with the configuration of esb module for your deployment. Now you have to inform the puppet master about the nodes which you are going to install WSO2 ESB within 1 minute.

Go to the /etc/puppet/manifests/site.pp script in the puppet master node.

Add the host name of the agent node at the end of that file as below.

node 'host1.sampledomain.com' inherits params{
class { 'esb':
version => '4.8.0',
offset => 0,
maintenance_mode => 'refresh',
owner => 'root',
group => 'root',
target => '/mnt/wso2/',
}
}

Here you have included the name of the module which you have previously configured and copied in to the /etc/puppet/modules directory. It will automatically pick up the class 'esb' inside the init.pp and start the execution. Since we have inherited the 'params' class, it will use the parameters defined there.

Now you are all set. Just restart the puppet server.

sh /etc/init.d/puppetmaster restart ( or any other alternative method)

Run the puppet agent from the agent node where you need to install the WSO2 ESB.

Now you are ready to see the magic. You have a brand new server which only has JAVA and puppet agent installed. You run the following command.

sudo puppet agent -t
oops. What hapenned. You may get a message about a security certificate issue. Don't worry, this happens this time only. What has just happened is puppet master communicates with only the allowed hosts via SSL. Therefore you need to allow this node by signing the certificate from the puppet master.

Go to puppet master and issue the following command.

sudo puppet cert sign –all

Now you are all set. Go to the puppet agent and type the following command.

sudo puppet agent -t

Now you can see all the files are downloaded to your new server less than 1 minute. Your server is ready to ROCK !!!

Check the file system and the log to see your WSO2 ESB is up and running.

Check on the /mnt/wso2 directory and make sure that WSO2 ESB server is installed there. Now check the wso2carbon.log file and confirm that your ESB server is up and running.


Now all done and do the last 2 steps for rest of your serves and do …...................

Comments

  1. https://github.com/wso2/Puppet/tree/master/modules/esb link is dead

    ReplyDelete

Post a Comment

Popular posts from this blog

WSO2 ESB tuning performance with threads

I have written several blog posts explaining the internal behavior of the ESB and the threads created inside ESB. With this post, I am talking about the effect of threads in the WSO2 ESB and how to tune up threads for optimal performance. You can refer [1] and [2] to understand the threads created within the ESB. [1] http://soatutorials.blogspot.com/2015/05/understanding-threads-created-in-wso2.html [2] http://wso2.com/library/articles/2012/03/importance-performance-wso2-esb-handles-nonobvious/ Within this blog post, I am discussing about the "worker threads" which are used for processing the data within the WSO2 ESB. There are 2 types of worker threads created when you start sending the requests to the server 1) Server Worker/Client Worker Threads 2) Mediator Worker (Synapse-Worker) Threads Server Worker/Client Worker Threads These set of threads will be used to process all the requests/responses coming to the ESB server. ServerWorker Threads will be used to pr

How puppet works in your IT infrstructure

What is Puppet? Puppet is IT automation software that helps system administrators manage infrastructure throughout its lifecycle, from provisioning and configuration to orchestration and reporting. Using Puppet, you can easily automate repetitive tasks, quickly deploy critical applications, and proactively manage change, scaling from 10s of servers to 1000s, on-premise or in the cloud. How the puppet works? It works like this..Puppet agent is a daemon that runs on all the client servers(the servers where you require some configuration, or the servers which are going to be managed using puppet.) All the clients which are to be managed will have puppet agent installed on them, and are called nodes in puppet. Puppet Master: This machine contains all the configuration for different hosts. Puppet master will run as a daemon on this master server. Puppet Agent: This is the daemon that will run on all the servers, which are to be managed using p

How to configure timeouts in WSO2 ESB to get rid of client timeout errors

WSO2 ESB has defined some configuration parameters which controls the timeout of a particular request which is going out of ESB. In a particular  scneario, your client sends a request to ESB, and then ESB sends a request to another endpoint to serve the request. CLIENT->WSO2 ESB->BACKEND The reason for clients getting timeout is that ESB timeout is larger than client's timeout. This can be solved by either increasing the timeout at client side or by decreasing the timeout in ESB side. In any of the case, you can control the timeout in ESB using the below properties. 1) Global timeout defined in synapse.properties (ESB_HOME\repository\conf\) file. This will decide the maximum time that a callback is waiting in the ESB for a response for a particular request. If ESB does not get any response from Back End, it will drop the message and clears out the call back. This is a global level parameter which affects all the endpoints configured in ESB. synapse.global_timeout_inte