How to Pass Values Between Components in IBM UrbanCode Deploy
JohnnyShieh 060000KVTN Visits (1778)
One of the great uses of IBM UrbanCode Deploy with Patterns (UCDP) is the ability to break up a Heat Orchestration Template (HOT) into individual components that can be reused in different combinations to form new applications. However, one of the capabilities lost in the breaking up of the singular HOT file into individual, stand-alone Components is the ability to set and share dynamic values generated during execution of HOT scripts. Whereas these values can be gathered and kept during the single instance execution of the HOT document, the fact that Components are meant to execute in stand-alone mode implies that variables can not be shared across Component instances.
However, one needs this ability to share common data. For example, I have a UCDP application that will install an Apache server and a mysql server. These servers will exist as stand-alone entities. However, at least one of the two entities needs to know how to find the other in order for them to synchronize their connections. How does one server learn the IP address of the other if they are installed separately and given dynamic IP addresses at the time of install?
There are documented methods to pass this information along, but actually enacting this capability is non-trivial.
This blog entry will walk the reader through the steps to share variables, providing pictures to go along with the instructions. And at the end of the posting, links to supporting documents will be provided. Once one sees an example implementation of the functions, the online documentation should be easier to understand in terms of perspective.
What does one know?
One knows that two virtual machines (VM) will be installed. One knows that each of the installed VMs will receive a dynamic IP address which will be allocated at the time of the image install. One knows that the application that installs one VM will be the same application that installs the second VM. Thus, there is a common environment where the IP address of the first installed system can be passed to the second installed system. The trick is assembling the steps so that this data can be declared by one VM and accessed by the other.
The steps are roughly:
First, a Component is created that is executed after the VM is created. This Component is called "source" and will consists of a shell script and post-execution plugin which will capture the relevant data.
The Component is created within UCDP via the path: Component -> Create New Component -> (edits to name component, then Save) -> Version -> Import New Versions -> Processes -> Create New Process -> (edits to name process, then Save) -> Edit
Within the design palette: Scripting -> Shell -> Shell (place your mouse on the Shell icon and drag it into the workspace)
One will automatically go into Process-Shell edit mode. The process is thus defined:
Unfortunately, the Shell Script window is very small. The shell script is:
Before the user Saves this property, they must create a new post-processing plugin. These plugins are expected to be written in Java script. The user selects the "New" button under "Step Default" and an edit window will appear:
Again, the edit window is small. The code to gather two variables is:
This function searches for the key phrases "Step Output is" and "Step Output2 is" and removes the strings leaving the value of the IP address and hostname string.
This post-processing plugin is then saved.
Next the user goes back to the Step Palette and selects the option: Environments -> Create Environment Property. The user selects two of these entities because two variables are to be declared and set. These two will follow a simple format:
And then, these three Elements that make this process are tied together:
Note that the Shell gathering the variables executes first, does the post processing, then the actual variables get defined second.
Then, the user creates a second component, called "dest" which executes on the second created VM. This is to prove that the values from one VM can be passed to the second VM to be used in configuration and whatever else the user desires:
And the simple shell script is:
Supporting documentation links for items discussed above:
Many thanks to T. Neal for educating the author on this whole process.