Archive for the ‘depsync’ Category

Deployment synchronization of WSO2 process of syncing deployment artifacts across the product cluster. The goal of depsync is to synchronize  artifacts (proxies, APIs, webapps etc) across all the nodes When a user upload or update an artifact. If not for depsync when a artifact is updated by the user, those artifacts should be added to other servers manually. Current depsync is carried out with a SVN repository. When a user updates an artifact, manager node commit the changes to the central SVN repository and inform worker nodes that there is a is a artifact update. Then worker nodes get a SVN update from the repository.

This article explain an alliterative way of achieving the same goal of debsync. This method eliminates the overhead of maintaining a separate SVN server for depsync, instead uses rsync tool which is pre installed in most of the unix systems..

rsync is a file transfering utility for unix systems. rsync algorithm is smart so that only transfer the difference of the files. rsync can be configured to use rsh or rss as the transport.

Prerequisites

Icron is a utility that watch for file system changes and let user defined commands to trigger when an file system changing event occurred.
Install incron if you don’t already have it installed

	sudo apt-get install incron
	
Configure Deployment synchronization

1) Add host entries of all worker nodes

vi /etc/hosts
192.168.1.1 worker1 worker1.wso2.com
192.168.1.2 worker2 worker2.wso2.com
192.168.1.3 worker3 worker3.wso2.com

2. Create SSH keys on the management node.

ssh-keygen -t dsa

3). Copy the public key to the worker nodes so you can ssh to the worker nodes without providing password each time.

ssh-copy-id -i ~/.ssh/id_rsa.pub worker1.wso2.com
ssh-copy-id -i ~/.ssh/id_rsa.pub worker2.wso2.com
ssh-copy-id -i ~/.ssh/id_rsa.pub worker3.wso2.com

4) Create a script file /opt/scripts/push_artifacts.sh with the below content

The script assumes your management server pack  is located on home/ubuntu/manager/ where as worker nodes are on /home/ubuntu/worker in every worker node.

#!/bin/bash
# push_artifacts.sh - Push artifact changes to the worker nodes.

master_artifact_path=/home/ubuntu/manager/wso2esb4.6.0/repository/deployment/
worker_artifact_path=/home/ubuntu/worker/wso2esb4.6.0/repository/deployment/

worker_nodes=(worker1 worker2 worker3)

while [ -f /tmp/.rsync.lock ]
do
  echo -e "[WARNING] Another rsync is in progress, waiting..."
  sleep 2
done

mkdir /tmp/.rsync.lock

if [ $? -eq 0 ]; then
echo "[ERROR] : can not create rsync lock";
exit 1
else
echo "INFO : created rsync lock";
fi

for i in ${worker_nodes[@]}; do

echo "===== Beginning artifact sync for $i ====="

rsync -avzx --delete -e ssh $master_artifact_path ubuntu@$i:$worker_artifact_path

if [ $? = "1" ]; then
echo "[ERROR] : rsync failed for $i";
exit 1
fi

echo "===== Completed rsync for $i =====";
done

rm -rf /tmp/.rsync.lock
echo "[SUCCESS] : Artifact synchronization completed successfully"

The above script will send the artifact changes to all the worker nodes.

5) Trigger push_artifacts.sh script when an artifact is added, modified or removed.

Execute below command to configure icron.

incrontab -e

Add the below text in to the prompt opened by above step.

/home/ubuntu/wso2/wso2esb4.6.0/repository/deployment/server IN_MODIFY,IN_CREATE,IN_DELETE sh /opt/scripts/push_artifacts.sh

Above text tell icron to watch on the file changes (File edits, creations and deletions) of the directory under /home/ubuntu/wso2/wso2esb4.6.0/repository/deployment/server and trigger push_artifacts.sh script whenever a such kind of directory structure change is occured. Simply saying, icron will execute push_artifacts.sh (Script created in step 4) in an event of a artifact change of wso2esb is occured. Thus in case of any artifact change of the master node, all the changes are sync to the all worker nodes which is exactly the goal of deployment synchronization.

Advantages over SVN based debployment synchronization
  • No SVN repository is needed.

There is no overhead of running a SVN server

  • Carbon servers are not needed to cluster to have deployment synchronization

If you are using SVN based deployment synchronization or Registry based deployment synchronization, you need to cluster carbon servers. But this method does not require clustering.

  • Can support multiple manager nodes

In SVN based depsync system is limited to single manager nodes due to the reason that there is a posibility of a node get crashed due to SVN commit conflicts occur when multiple managers commiting artifact updates concurrently. The reason for this is SVN does not support concurrent commits. That issue is not applicable since. However syncing script should be updated to synchronize artifacts among manager nodes also.

  • No configurations needed on any of the worker nodes.

Practically in a real deployment there are one or two (maximum) management node and many worker nodes. Since configurations are done only in the management node,  new worker nodes can be added without doing any configurations from the worker node side. Only needed to add the hostname of the new worker node to the artifact update script  created in step 4.

  • Take backup of the artifacts.

rsync can be configured to backup artifacts to another backup location.

Disadvantages over SVN based deployment synchronization
  • New nodes needed to be added manually.

When a new worker node is started, it should be added manually added to the script.

  • Artifact path is hard coded in the script.

Carbon server should be placed under /home/ubuntu/wso2 (path specified in the script). If the Carbon server pack is moved to another location, script also has to be updated.

Note : This method is not one of the recommended way of doing deployment synchronization.

Advertisements