In my above article, we saw through a use case how to take advantage of traceability in a fully distributed architecture [link].
In this article, we will see in the same context, how we can take advantage of fabric8 registry by centralizing the configuration of the whole Camel routes and ActiveMQ.
As shown in the diagram above, all camel routes and ActiveMQ Broker in JBoss Fuse retrieves their configuration data in the Fabric8 registry, such use has allowed to:
- Centralize all configuration data in one place, which makes the operation simple and trivial.
- Distinguish the configuration data for different environments: Dev, Test, qualif & Prod.
- Automate the creation and update of the configuration data.
- Encrypt all credentials configuration. (No password is visible in the cfg files)
Let’s start an example to see how it works:
First we should install the ‘zookeeper-commands’ feature:
In fabric8 features are also controlled by fabric8, for this reason the good old ‘feature:install’ command will not work.
I resulted in installing the zookeeper-commands feature through the Hawtio console.
In the Hawtio console go to ‘Wiki’ → edit fabric features → search for zookeeper and select zookeeper-commands → click the ‘Add’ buttom and finally click ‘save’
Now, we can find all the zk commands on the console:
zk:create zk:delete zk:edit zk:export zk:get zk:import zk:kill zk:list zk:set
Example of camel route configuration:
In this camel route, we have used the fabric registry for 2 reasons: centralize camel configuration, and the recipient list lookup.
Below part of this route camel:
All variables defined in the route camel, will be substituted with the contents of a ZooKeeper node using the zk URL. The cfg file resulting to this route will be like:
Using ZooKeeper commands, we will execute the following commands to create initial configuration in fabric8 registry:
With these elements, the route camel became pretty simple. On startup, it retrieves basic initialization configuration data from fabric8 registry.
The same idea has been applied for activemq configuration, by externalizing the common configuration, like regarding destination policy, because the most time we apply the same policy in all brokers, like the prefix or the suffix for DLQ, or discarding expired messages.
I hope that this post will give you an idea about the different possibilities that are offered by fabric8.
If you-have any questions, feel free to ping me via twitter @a_bouchama.