After reading this article ‘Create and customize virtual application patterns‘ and as being an IT Architect, my first question was ‘How difficult it is to create a pattern type?’. So, I started for my first pattern type ever with a very simple scenario ‘A standalone server’ and try to build a pattern type for it. I know this scenario is very simplistic but it helps to understand the different concepts behind the pattern-type. Other articles will follow with more complex scenarios. I recommend each beginner to start with such scenario as it will teach you the basic concepts, the deployment process, the troubleshooting possibility…
I would like to stress the difference between pattern-type and pattern. A pattern-type provides all components, links, scalability rules… to build a pattern. The best example is the pattern-type for Web-Application (see demo) which provides Enterprise Application, Database components and scalability rules to design your own pattern which you will be able to deploy multiple time. So in this article we show how to create a pattern-type which requires more effort than create a pattern based on a pattern-type. ISV and/or company with home made application which not fit one of the existing pattern-type would be interested in this as pattern-type allows to put all the infrastructure intelligence in the pattern-type in order to deliver the best pattern for your customer.
Don’t forget also that next to virtual application pattern with their pattern-type you have to capability to create virutal system pattern, which allows you to deploy topology with your own images and scripts.
At the end of this article, you will find a video showing this scenario.
I realized this scenario on SmartCloud Application Workload Service but of course it is applicable to IWD or PureSystems.
Development environment setup:
To setup your development environment, please follow this article.
Scenario:
– The pattern type will contains only 1 server.
– The server will have one parameter.
– The deployment process will log a message when the ‘deployment’ starts the installation.
– The deployment process will log a message at another point of the deployment.
Some concepts:
– A pattern-type is generally composed of one plugin composing the ‘pattern-type’ definition and one or more plugin composing functionality provided by this pattern-type. If we take as example the ‘Hello’ sample provided by the article above, the ‘pattern-type’ is ‘patterntype.hello’ and we have three plugins hello, hcenter and hlink. The number of plugin is based on an architecture choice.
– We can decomposed a plugin in two main parts: The application-model which defines the different components and links to design a virtual application pattern and the physical-model which defines the different virtual machines and scripts that have to be launched on the target cloud. Two mechanisms are provided to map the application-model to the physical model, one based on java code and the other on templates. The preferred and recommended one is the template but if your deployment is more complex you can use the java mechanism or better a mix of template/java by realizing simple operations in the template and more complex operations using java. In this article I will use only the template and I think at 99% the template is enough. The template is transformed at run-time into Java code using Apache Velocity, that’s mean in your template you can use Velocity macro to provide directive to the transformation process.
Setup
We have to setup first our Eclipse project, basically you have to:
1) create a new workspace.
2) Create a new pattern-type using the wizard provided by the PDK. ‘New’->’IBM Workload Pattern Type Project’ and enter the following information:
then click ‘Finish’.
3) create a new pattern plugin project using again the PDK wizard. ‘New’ -> ‘Project’ -> ‘IBM Workload Plug-in Project’ and enter the following information.
4) After, we have to provide a reference to the pattern-type in this new plugin. This is done by editing the config.json file located in the plugin directory and modify it as follow:
{
"name":"plugin.mynameLab",
"version" : "1.0.0.0",
"patterntypes":{
"primary":{
"patterntype.mynameLab":"1.0"
}
},
"packages":{
"PLUGIN.SLAVE": [
{
"parts": [
{
"part": "parts\/slave.scripts.tgz"
}
]
}
]
}
}
Don’t pay attention for the time being at the packages element.
Application-model:
The application model is defined in the plugin/appmodel/metadata.json. In the metadata.json we define each element of the application model such components, links, policies… In my scenario I have only one component and thus my m metadata.json file will look like:
[
{
"id": "slave",
"type": "component",
"label": "Slave",
"attributes": [
{
"id": "slaveAttr1",
"type": "string",
"required": false,
"label": "Attribute1",
"description": "Slave Attribute 1"
}
]
}
]
I have defined the component name, label, description and I specify that this component have one required string attribute called ‘attr1’ initialized with the string “str”.
We have to import from the PDK example the ‘plugin.com.ibm.sample.hellocenter/plugin/appmodel/images’ directory in order to import the images.
After having designed the application-model in the metadata.json, I’m ready to test it.
1) Again the PDK wizard will be very helpful: Select the pattern-type project, right-click and select ‘IBM Workload Plugin’ -> ‘Build’.
2) Open you SCAWS portal, select ‘Cloud’->’PatternTypes’.
3) Click on the green ‘plus’ and select the *.tgz located in the patterntype.mydemo/export directory.
4) Once uploaded you have to enable the plugins, this can be done by selecting the plugin in the right panel and selecting ‘enable’.
5) Click on ‘Patterns’->’Virtual Applications’ and click ‘plus’, select ‘patterntype.mynameLab’ and ‘Start Building’ a new pattern and you can see you have the component, drag and drop it in the editor area and you will see the attribute.
Put a value in the ‘Attribute1’ and save it.
We can not deploy it yet as we didn’t create the physical-model yet;
Physical-model:
The physical-model is composed of a vm template file defining the virtual element that should be deployed and their role regarding the application model. We have also to create an OSGI component to convert this template to a topology. The PDK will create at the same time the OSGI Component, the template and update the MANIFEST.MF.
1) Select the plugin project, OSGI Service Component
2) Right-click, ‘New’->’OSGI Service Component and enter the following informations:
3) update the vm-template as follow:
{
"vm-templates": [
{
"persistent": false,
"name": "${prefix}-MasterSlave",
"roles": [
{
"parms": {
"SlaveAttr1": "$attributes.slaveAttr1"
},
"type": "slave",
"name": "slave"
}
],
"packages":["PLUGIN.SLAVE"]
}
]
}
We can see I defined an attribute ‘Attr1’ for this virtual element. The attribute is initialized with the ‘slaveAttr1’ defined in the metadata.json of the appmodel. The value is set while designing the virtual application pattern.
I also specified which package must be used during the deployment. A package contains a number of scripts that are send to the vm and run in a specific order. The scripts can be subdivided in roles (here ‘slave’).
As the deployment engine use Java transformer to transform the application-model into a physical-model and we use a template we have to setup velocity to transform the template into java code. This is done via the MANIFEST.MF and an OSGI-INF file.
First the OSGI-INF file: We can see that the PDK automatically creates the corresponding xml in OSGI-INF directory in order to transform the template:
The link to the application model is done via the name of the component (here:slave) which have to be the same as the ‘id’ attribute of the application model (metadata.json file).
The link to the physical model is done via the ‘component.template’ property defining the location of the physical model template.
Now we have to register this service in the plugin, this is done via the MANIFEST.MF by adding a service component. Multiple service components can be set by separating them with a ‘comma’ and again this was already done by the PDK.
Manifest-Version: 1.0 Service-Component: OSGI-INF/slave.xml Bundle-RequiredExecutionEnvironment: JavaSE-1.6 Bundle-Name: plugin.mynameLab Bundle-SymbolicName: plugin.mynameLab; singleton:=true Bundle-Version: 1.0.0 Bundle-ManifestVersion: 2 Import-Package: com.ibm.json.java,com.ibm.maestro.common.http,com.ibm .maestro.common.utils,com.ibm.maestro.model.transform,com.ibm.maestro .model.transform.template,com.ibm.websphere.ras,com.ibm.websphere.ras .annotation,com.ibm.ws.ffdc
Remember, we defined parts in ‘packages’ “slave.scripts” element of the the config.json file and specified in the vm-templates to use this the package. We also defined in the vm-templates the role “slave” for this virtual element. That’s mean we have to create in the plugin directory the following structure in order to get these files uploaded in our vm and run them. Let’s use the PDK to do that:
– Right-click and select ‘New’->’Plug-In Part’ and fill it as follow:
then ‘New’->’Plug-In Role’ and fill it as follow:
You can delete the directory ‘mynamelab.scripts’.
First the install.py scripts will be launched, in this scripts we will ask to load the ‘scripts’ directory of the specific role and run it followed by the start.py.
start.py
import logging
import maestro
logger = logging.getLogger("slave/start.py");
maestro.role_status = 'STARTING';
slaveattr1 = maestro.parms['SlaveAttr1'];
logger.debug("Start Slave %s" % slaveattr1);
maestro.role_status = 'RUNNING';
we can see here that the SlaveAttr1 will be printed in the log file.
Final Test:
Now, we are ready for our final test, as the patterntype plugin has be already loaded, we need only to reload the plugin but with a new version number. For that you can increment the version attribute in the config.json and then relaunch the build.xml located in the plugin.depends project or You can also just build the individual plugin with its build.plugin.xml file, and load it from the plugin’s export directory.
To upload the plugin, just go in the SCAWS portal, click on ‘cloud’->’System Plugins’, click ‘plus’ and load the *.tgz file located in the export directory of the plugin.mynameLab project.
Now, you are ready to deploy your virtual application pattern based on your own pattern-type.
Once deployed you can look at the logs and particularly at the role log where you will find an entry containing the ‘Attribute1″ value.
Video:
Here the video demonstrating the above:
[youtube]http://www.youtube.com/watch?v=UHBkeV5Wzuk[/youtube]
NB: This video was done on an earlier version of the PDK, the plugin.depends doesn’t exist anymore.
Conclusion:
Knowing that I’m really comfortable with Eclipse environment and Java, I don’t have skills in python, I found the realization for this very simple scenario not difficult. It took me a week-end to create this scenario and I was really a novice in this area.
Architecture skills needed: Component-model (++), Operational-model (++)
Realization skills needed: Eclipse (+), Python (++), Velocity (+), Maestro library (+++), JSON (+).
Of course, depending on the software you like to deploy on each virtual machine, you will need skilled people able to deploy in an automatic way the software and automate also its configuration.
Source of information:
– Plug-in Developer’s Guide IBM Workload Deployer (needs an ibm.com id which can be created online).