Article: Using Terracotta for Configuration Management

Discussions

News: Article: Using Terracotta for Configuration Management

  1. "Using Terracotta for Configuration Management" by JR Boyens details using Terracotta to propagate configuration management on the fly across a network, such that a client can pull up its configuration data live. Terracotta suggests that this is an excellent use of the platform; while this article is cursory, the concept is valid.
    Configuration management, for lack of a better term, is a serious problem for a lot of growing businesses. Having only one server and, therefore, one configuration is not really something that requires a lot of management. Once you start to get past 5 – 10 servers with different configurations for each one, it gets to be a little much. Continue on and very quickly configuration gets to be a real problem. Making sure that the right host/app runs the right configuration at the right time in a dynamic environments is tricky at best. After evaluating numerous possible solutions we have finally settled on using Terracotta. We can easily share object graphs for managing our configurations across all of our servers. This simplifies having each node running many different applications with unique configurations. The purpose of this article is to let you know about our issues, what we initially thought of doing, what we ultimately decided upon, and how we implemented it. Terracotta, if you're not familiar, is a sort of network shared memory system. It shares object graphs across the cluster, through something called a "shared root." You declare a Java field as a shared root and then Terracotta handles updating all the nodes in the "cluster" with the information as it changes. It avoids excessive overhead by only sending deltas to keep the objects in sync. The Terracotta folks do a great job explaining their technology in their Introduction to Terracotta - and you can see the object graph being declared as a shared root in the configuration later in this article. Speaking of what this article is about: basically, the Java Properties system is based on maps. You feed the Properties object a key, and get a value out. What we needed to be able to do is specify a "global properties" object that would allow us to update the properties after the application had been deployed, and alter values based on hostnames and server roles.
  2. Nice use case. It is true. Terracotta works really well for distributed config mgmt. Another kewl thing that you can do JR, is to use Terracotta Cluster Membership events (JMX listening type pattern). http://forge.terracotta.org/projects/jmx-util/ We will tell you when a node goes down. This means you can dynamically update config based on real time cluster shape and size. Cheers, --Ari
  3. Interesting that you mention this. I'm in the process of working on a project which I plan to open source sometime later next month. In regards to dependencies, my goal is to minimize the third party dependencies from the clients point of view. In order to do this, I'm using JMX to handle the communication between client and server and also use JMX to handle the clustering aspects has well. I'd love to get some feedback when the initial version is released. I'm also interested in hearing about what others are doing now in this regards has well. Best Regards, Richard L. Burton III
  4. http://forge.terracotta.org/projects/jmx-util/
    Looks like that link is now http://forge.terracotta.org/releases/projects/jmx-util/