Rollin’ up properties like a boss

Imagine a production environment with 10 JBoss application servers. It may not make sense for some folks to have 10 hosts in lower environments like QA and DEVELOPMENT. Perhaps you only want to have one in some environments. The best approach to managing your properties is to declare the highest amount globally and reference them environmentally. Define the entire set of hosts in your properties/global.xml and have the extra hosts point to a default, then just define what you need in each environment’s properties file. By doing this, you’re managing all the ip addresses of your hosts in one spot. Here’s what I mean by that:

Now let’s take a look at properties/environment/development.xml this file is called development.xml because we’re calling the environment development inside the environments.xml and it is in the environment folder because these are environment specific properties. In development, we want to have two hosts. We just define what we need and IP_3 to IP_10 will point to 10.0.1.1 or you can redefine them. It doesn’t matter much because we don’t plan to use them.

In QA, we want 4 hosts, so we do the same thing:

Finally, in production we will define all 10 hosts.

Now, let’s say you want to be able to reference the ip address of the machine you’re actually running your script on, let’s call this property MY_IP_ADDRESS this property would need to be defined on the host level in properties/agent/agentName.xml In this case, the file name is jboss-prod01.xml because in our agent.xml we’ve defined this agent name as jboss-prod01. Now, instead of hardcoding the ip address of each host inside single files, you can just reference the properties already defined, like so:

And jboss-prod02…

And jboss-prod03 for good measure…

Since we’ve said export=”yes” to these properties, they will automatically be set in the environment of our scripts. This works nicely on unix and windows as you’d think. On unix you can just reference $MY_IP_ADDRESS inside a shell script or os.environ[‘MY_IP_ADDRESS’] in python or %MY_IP_ADDRESS% in .bat scripts and $env:MY_IP_ADDRESS in powershell. It all works, and it’s all awesome. Here’s a simple example of why we’d want this:

This one-liner runs this command on all hosts in the jboss role, this can be 1, 10, 100 or >1000 based on what we have defined in our environments.xml. Additionally, these actions happen in their own threads. If you are running a very large environment with thousands of hosts you can simply throttle the amount of hosts that are run at once with the attribute maxAgents=X so simple, so fun, why would we want this any other way ?

Inside post-deploy-check.py we have:

With this method, each host checks their own ip address. Alternatively, we can run this check on some alternate host to reach out to each of these hosts because we have all the ip addresses we need for all environments.


Leave a Reply