As you may know, WSO2 Governance registry is separated into three sub registries;
- Config registry - Stores the configurations and related information of a product
- Governance registry - Stores governance artifacts and other related information
- Local registry - Stores information that is local to a node in a cluster
Local registry, as its name implies, have to be local to that instance. Other two registries can be shared.
To start of with experimenting this setup with WSO2 Governance Registry, go ahead and download the latest stable WSO2 Governance Registry product from http://wso2.com/products/governance-registry/ After downloading, extract the zip file to a location of your interest, and copy the entire folder to another location to have a perception of the shared instance.
To avoid confusion, let me rename the directory name of the shared instance to wso2greg-4.6.0_remote. The version number of the extracted zip file may be different from this at the time of your download. Follow this with the version and change the procedure accordingly to reflect the version that you have downloaded. Let the local instance directory name be wso2greg-4.6.0. I've placed the two directories in my home directory. Therefore the two directories are, $HOME/wso2greg-4.6.0 and $HOME/wso2greg-4.6.0_remote. I'll refer to these two directories as GREG_HOME in respective contexts.
WSO2 governance registry uses inbuilt H2 database to store data related to above three registries. In a production environment however, it's recommended to use some other RDBMS such as MySQL as the registry DB. Therefore, in this tutorial, we shall use MySQL as the DB for the remote shared partition.
To install MySQL database point to my above blog post "Installing MySQL in Linux"
Assuming you have installed MySQL DB and running, you can now create the database named registrydb (the name can be anything you like) in MySQL as follows,
Let's first setup our remote shared instance (i.e. the directory named wso2greg-4.6.0_remote)
In fact, there is nothing much to do in this setup except modifying the configuration file named master-datasources.xml which you can find in GREG_HOME/repository/conf/datasources/ to use MySQL, instead of the built-in H2 database. Change the <datasource> of WSO2_CARBON_DB as shown below.
Note the <url>. You may use the phrase "localhost" instead of the loopback address 127.0.0.1 IP address. Further, change the port on which your MySQL runs. (3306 is the default configured MySQL port.)
registrydb part of the URL indicates the database we created earlier.
We need to copy the MySQL JDBC driver (a .jar file), which you can download from http://www.mysql.com/products/connector/, to GREG_HOME/components/lib/. And, this step needs to be done in the other node as well.
We can now start this instance of the WSO2 Governance registry by issuing the following command from GREG_HOME/bin
Here the -Dsetup option is to populate the created 'registrydb' in MySQL. We can now access the management console by navigating to the https://localhost:9443/carbon/ URL from your browser.
Now we can configure the other node (our local instance that's going to share the 'Config' and 'Governance' registries of the remote partition that we have already started). Therefore, what needs to happen is that, to inform this node about the remote 'Config' and 'Governance' registries that we intend to use. This is done in WSO2 Governance Registry by properly configuring the registry.xml and the master-datasources.xml configuration files.
Let's configure the registry.xml file. We need to tell this registry partition that we are going to use a remote 'Config' and 'Governance' registries. This is done by adding the following in the registry.xml file.
And further, we have to have a way to inform the mount instance location. That's done by adding the following in registry.xml.
Where x.x.x.x is the IP address of the remote partition. Since, the remote instance that we already started is in localhost that x.x.x.x = 127.0.0.1 (the loopback ip address). If you are setting this up in a true remote setup, change that IP address accordingly. Note that <id> tag matches the <instanceid> tag in the <mount> we configured earlier.
Now the registry partition location is been informed. Now we got to say, where the database of the remote instance resides. That database could ideally be in any location within the reachable network. It has to be configured in the master-datasources.xml file. Before that, we have to add one more addition to registry.xml file. It's listed below.
"jdbc/WSO2MountRegistryDB" will be a reference to the relevant <datasource> that we would next configure in the master-datasources.xml file. Now, let's move to master-datasources.xml file. There we would keep the default H2 database for the local registry. Additionally we got to say the DB instance where the 'Config' and 'Governance' registries reside. Add the following <datasource> in master-datasources.xml to achieve that.
I guess we are all set, except for one thing. Since we are going to run both the remote and local setup in the local machine itself, if you run the currently configured node, you would see an exception thrown in the console. The reason for this is that, we can't run two WSO2 products at the same time, since both would attempt to run on the same default port 9443. To avoid the conflict, we should set the offset for the next server that we are going to run in the carbon.xml in GREG_HOME/repository/conf. Open up carbon.xml and change the value for <offset> to 1. This will make this instance to start of with the port 9444. If you are running this setup in two different machines you may not need to do this change, though doing so would do no harm either.
Phew!!!. All done. Now we shall start this instance in the same way we started the earlier remote instance. In the console, you should see the following three lines among others, which indicate that two registries; 'Config' and 'Governance' have been mounted in the 'mountregistry'.
You may access the Management Console by browsing https://localhost:9444/carbon/ URL. In the Management console, click 'Browse' and expand the _system in the tree view. You should see blue arrow in front of 'config' and 'governance' nodes as shown in the following screenshot, indicating that it's mounted in a remote partition.
To start of with experimenting this setup with WSO2 Governance Registry, go ahead and download the latest stable WSO2 Governance Registry product from http://wso2.com/products/governance-registry/ After downloading, extract the zip file to a location of your interest, and copy the entire folder to another location to have a perception of the shared instance.
To avoid confusion, let me rename the directory name of the shared instance to wso2greg-4.6.0_remote. The version number of the extracted zip file may be different from this at the time of your download. Follow this with the version and change the procedure accordingly to reflect the version that you have downloaded. Let the local instance directory name be wso2greg-4.6.0. I've placed the two directories in my home directory. Therefore the two directories are, $HOME/wso2greg-4.6.0 and $HOME/wso2greg-4.6.0_remote. I'll refer to these two directories as GREG_HOME in respective contexts.
WSO2 governance registry uses inbuilt H2 database to store data related to above three registries. In a production environment however, it's recommended to use some other RDBMS such as MySQL as the registry DB. Therefore, in this tutorial, we shall use MySQL as the DB for the remote shared partition.
To install MySQL database point to my above blog post "Installing MySQL in Linux"
Assuming you have installed MySQL DB and running, you can now create the database named registrydb (the name can be anything you like) in MySQL as follows,
mysql> create database registrydb;
Let's first setup our remote shared instance (i.e. the directory named wso2greg-4.6.0_remote)
In fact, there is nothing much to do in this setup except modifying the configuration file named master-datasources.xml which you can find in GREG_HOME/repository/conf/datasources/ to use MySQL, instead of the built-in H2 database. Change the <datasource> of WSO2_CARBON_DB as shown below.
<datasource>
<name>WSO2_CARBON_DB</name>
<description>The datasource used for registry and user manager</description>
<jndiConfig>
<name>jdbc/WSO2CarbonDB</name>
</jndiConfig>
<definition type="RDBMS">
<configuration>
<url>jdbc:mysql://127.0.0.1:3306/registrydb</url>
<username>root</username>
<password>root</password>
<driverClassName>com.mysql.jdbc.Driver</driverClassName>
<maxActive>50</maxActive>
<maxWait>60000</maxWait>
<testOnBorrow>true</testOnBorrow>
<validationQuery>SELECT 1</validationQuery>
<validationInterval>30000</validationInterval>
</configuration>
</definition>
</datasource>
Note the <url>. You may use the phrase "localhost" instead of the loopback address 127.0.0.1 IP address. Further, change the port on which your MySQL runs. (3306 is the default configured MySQL port.)
registrydb part of the URL indicates the database we created earlier.
We need to copy the MySQL JDBC driver (a .jar file), which you can download from http://www.mysql.com/products/connector/, to GREG_HOME/components/lib/. And, this step needs to be done in the other node as well.
We can now start this instance of the WSO2 Governance registry by issuing the following command from GREG_HOME/bin
$ ./wso2server.sh -Dsetup
Here the -Dsetup option is to populate the created 'registrydb' in MySQL. We can now access the management console by navigating to the https://localhost:9443/carbon/ URL from your browser.
Now we can configure the other node (our local instance that's going to share the 'Config' and 'Governance' registries of the remote partition that we have already started). Therefore, what needs to happen is that, to inform this node about the remote 'Config' and 'Governance' registries that we intend to use. This is done in WSO2 Governance Registry by properly configuring the registry.xml and the master-datasources.xml configuration files.
Let's configure the registry.xml file. We need to tell this registry partition that we are going to use a remote 'Config' and 'Governance' registries. This is done by adding the following in the registry.xml file.
<mount path="/_system/config" overwrite="true">
<instanceId>mountInstance</instanceId>
<targetPath>/_system/config</targetPath>
</mount>
<mount path="/_system/governance" overwrite="true">
<instanceId>mountInstance</instanceId>
<targetPath>/_system/governance</targetPath>
</mount>
And further, we have to have a way to inform the mount instance location. That's done by adding the following in registry.xml.
<remoteInstance url="https://x.x.x.x:9443/registry">
<id>mountInstance</id>
<dbConfig>mountregistry</dbConfig>
<readOnly>false</readOnly>
<enableCache>true</enableCache>
<registryRoot>/</registryRoot>
<cacheId>root@jdbc:mysql:@127.0.0.1:3306:registrydb</cacheId>
</remoteInstance>
Where x.x.x.x is the IP address of the remote partition. Since, the remote instance that we already started is in localhost that x.x.x.x = 127.0.0.1 (the loopback ip address). If you are setting this up in a true remote setup, change that IP address accordingly. Note that <id> tag matches the <instanceid> tag in the <mount> we configured earlier.
Now the registry partition location is been informed. Now we got to say, where the database of the remote instance resides. That database could ideally be in any location within the reachable network. It has to be configured in the master-datasources.xml file. Before that, we have to add one more addition to registry.xml file. It's listed below.
<dbConfig name="mountregistry">
<dataSource>jdbc/WSO2MountRegistryDB</dataSource>
</dbConfig>
"jdbc/WSO2MountRegistryDB" will be a reference to the relevant <datasource> that we would next configure in the master-datasources.xml file. Now, let's move to master-datasources.xml file. There we would keep the default H2 database for the local registry. Additionally we got to say the DB instance where the 'Config' and 'Governance' registries reside. Add the following <datasource> in master-datasources.xml to achieve that.
<datasource>
<name>WSO2_MOUNT_REGISTRY_DB</name>
<description>The datasource used for registry and user manager</description>
<jndiConfig>
<name>jdbc/WSO2MountRegistryDB</name>
</jndiConfig>
<definition type="RDBMS">
<configuration>
<url>jdbc:mysql://127.0.0.1:3306/registrydb</url>
<username>root</username>
<password>root</password>
<driverClassName>com.mysql.jdbc.Driver</driverClassName>
<maxActive>120</maxActive>
<maxWait>900000</maxWait>
<testOnBorrow>true</testOnBorrow>
<validationQuery>SELECT 1 FROM DUAL</validationQuery>
<validationInterval>30000</validationInterval>
</configuration>
</definition>
</datasource>
I guess we are all set, except for one thing. Since we are going to run both the remote and local setup in the local machine itself, if you run the currently configured node, you would see an exception thrown in the console. The reason for this is that, we can't run two WSO2 products at the same time, since both would attempt to run on the same default port 9443. To avoid the conflict, we should set the offset for the next server that we are going to run in the carbon.xml in GREG_HOME/repository/conf. Open up carbon.xml and change the value for <offset> to 1. This will make this instance to start of with the port 9444. If you are running this setup in two different machines you may not need to do this change, though doing so would do no harm either.
Phew!!!. All done. Now we shall start this instance in the same way we started the earlier remote instance. In the console, you should see the following three lines among others, which indicate that two registries; 'Config' and 'Governance' have been mounted in the 'mountregistry'.
[2013-10-21 16:00:46,379] INFO {org.wso2.carbon.registry.core.jdbc.EmbeddedRegistryService} - Configured Registry in 116ms
[2013-10-21 16:00:46,408] INFO {org.wso2.carbon.registry.core.jdbc.EmbeddedRegistryService} - Connected to mount at mountregistry in 3ms
[2013-10-21 16:00:46,606] INFO {org.wso2.carbon.registry.core.jdbc.EmbeddedRegistryService} - Connected to mount at mountregistry in 0ms
You may access the Management Console by browsing https://localhost:9444/carbon/ URL. In the Management console, click 'Browse' and expand the _system in the tree view. You should see blue arrow in front of 'config' and 'governance' nodes as shown in the following screenshot, indicating that it's mounted in a remote partition.
