This site contains the documentation that is relevant to older WSO2 product versions and offerings.
For the latest WSO2 documentation, visit https://wso2.com/documentation/.

Configuring SVN-Based Deployment Synchronizer

Owned by Former user (Deleted)
Last updated: Jul 29, 2016
4 min read

This section describes how to set up the DepSync repository in Subversion (SVN). Although DepSync can use the Subversion package installed on the local server, it is not recommended for production, so use the SVNKit instead as described in the following steps. If you want to learn more about installing Subversion specifically on Fedora 18/17 and CentOS/Red Hat (RHEL), see http://www.if-not-true-then-false.com/2010/install-svn-subversion-server-on-fedora-centos-red-hat-rhel/.

Important

  • For all products based on Carbon 4.4.x, please use only SVN version 1.7 or 1.8 for working copies (SVN repositories added to the deployment synchronizer) and on your servers.
  • See the release matrix to identify the version of WSO2 Carbon that your WSO2 product is based on. If your product is based on Carbon 4.2.0, see SVN-Based Deployment Synchronizer in the clustering guide for Carbon 4.2.0 based products for configuration instructions.
  • Using SVN Deployment Synchronizer with SSH protocol is not supported.

Tip: The deployment synchronizer can be useful when WSO2 products are used as a platform for developers to develop their artifacts and do cluster-wide tests. However, if the artifacts are static and done to the production system without transaction loss, the best way is to deploy new artifacts in a round robin fashion.

  1. Remove Node1 from the LB pool.
  2. Wait until all transactions are processed by Node1.
  3. Shutdown Node1.
  4. Deploy new artifacts to Node1.
  5. Start Node1 in a testing domain. 
  6. Test Node1 with testing transactions and verify that node is functional OK.
  7. Shutdown and start node1 and switch it back to the LB.

In above manner roll out new changes to every server in a round robin fashion. This method can be used when deploying CAR files to a server. This will only work when deployment synchronization is disabled.

The following steps help you set up your SVN repository.

  1. Download and install SVNKit from http://product-dist.wso2.com/tools/svnkit-all-1.8.7.wso2v1.jar into the <PRODUCT_HOME>/repository/components/dropins folder.
  2. Download http://maven.wso2.org/nexus/content/groups/wso2-public/com/trilead/trilead-ssh2/1.0.0-build215/trilead-ssh2-1.0.0-build215.jar and copy it to the <PRODUCT_HOME>/repository/components/lib folder. This .jar file is necessary for the SVNKit to work as expected.
  3. In a console window, enter the following command to create a new repository: 
    svnadmin create <PathToRepository>/<RepoName> 

    For example: 
    svnadmin create ~/depsyncrepo

  4. Open <PathToRepository>/<RepoName>/conf/svnserve.conf and set following lines to configure authentication for the new repository.
    anon-access = none         (Specifies what kind of access anonymous users have; in this case, none)
    auth-access = write       (Specifies what authenticated users can do; in this case, they can write, which also includes reading) 
    password-db = passwd     (Specifies the source of authentication; in this case, the file named passwd, which resides in the same directory as svnserve.conf)

  5. Open <PathToRepository>/<RepoName>/conf/passwd and add the following line in the format of <username>:<password> to add a new user:
    repouser:repopassword

The SVN repository is now available with the user credentials you specified. If you want to test and further configure the repository, see the following references:

After you have created the repository, the next step is to enable DepSync on the manager and worker nodes.

Enabling DepSync on the manager node

You configure DepSync in the <PRODUCT_HOME>/repository/conf/carbon.xml file on the manager node by making the following changes in the <DeploymentSynchronizer> tag:

  1. Enable the DepSync feature: <Enabled>true</Enabled>
  2. Automatically commit local repository changes to the central repository (only enable this on the manager node, which is the node that receives server admin requests as per our deployment pattern): <AutoCommit>true</AutoCommit>
  3. Automatically update the local repository with changes from the central repository: <AutoCheckout>true</AutoCheckout>
  4. Specify the repository type (in this case, Subversion): <RepositoryType>svn</RepositoryType>
  5. Specify the location of the repository with the access protocol: <SvnUrl><AccessProtocol>://<PathToRepository>/<RepoName>/</SvnUrl>
  6. Specify the user name you defined in the last section: <SvnUser>repouser</SvnUser>
  7. Specify the password you defined in the last section: <SvnPassword>repopassword</SvnPassword>
  8. Enable tenant-specific configurations if needed: <SvnUrlAppendTenantId>true</SvnUrlAppendTenantId>

The final configuration for the management node should be similar to the following:

 <DeploymentSynchronizer>
    <Enabled>true</Enabled>
    <AutoCommit>true</AutoCommit>
    <AutoCheckout>true</AutoCheckout>
    <RepositoryType>svn</RepositoryType>
    <SvnUrl>https://svn.example.com/depsync.repo/</SvnUrl>
    <SvnUser>repouser</SvnUser>
    <SvnPassword>repopassword</SvnPassword>
    <SvnUrlAppendTenantId>true</SvnUrlAppendTenantId>
</DeploymentSynchronizer>

When working with two manager nodes

In a scenario where there are two manager nodes, if both servers start with the same default files in <PRODUCT_HOME>/repository/deployment/server an error occurs. The second management node should not have these default files within its <PRODUCT_HOME>/repository/deployment/server location. To avoid conflicts with regards to commits from the second node, the second node should not have the set of files that the first node has committed when the second node connects to the cluster.

Important: The recommended way to use multiple manager nodes is to specify one node as active and the rest as passive nodes. For example, when two manager nodes are required to be running, one node must be an active node and the other must be a passive node. Both manager nodes are set up and run as manager nodes, but the load balancer of port 9443/9763 must be configured to the active node only. The passive node must be configured as the failover node so that the data is forwarded to the passive node when the active node is not alive. This ensures that the same artifact is not deployed from both manager nodes simultaneously, which will move the deployment synchronizer to an inconsistent state.

Now that we have completed configuring DepSync on the manager node, we will configure it on the worker nodes.

Enabling DepSync on the worker nodes

You enable DepSync on the worker nodes the same way as on the manager node, with one change: set <AutoCommit>false</AutoCommit>, since worker nodes do not handle server admin requests.

Therefore, the final configuration for worker nodes will be as follows:

<DeploymentSynchronizer>
    <Enabled>true</Enabled>
    <AutoCommit>false</AutoCommit>
    <AutoCheckout>true</AutoCheckout>
    <RepositoryType>svn</RepositoryType>
    <SvnUrl>https://svn.example.com/depsync.repo/</SvnUrl>
    <SvnUser>repouser</SvnUser>
    <SvnPassword>repopassword</SvnPassword>
    <SvnUrlAppendTenantId>true</SvnUrlAppendTenantId>
</DeploymentSynchronizer>

You have now configured DepSync for the cluster, which will ensure that all nodes in the cluster will have the same configurations.