Having hooked up UrbanCode Deploy with Patterns (UCDP) to OpenStack and UrbanCode Deploy (UCD), it’s time to take a look at a “HelloWorld”-style example. I’ll work through a single-server UCDP blueprint, deploying a single UCD component to it.
Here’s the OpenStack network topology onto which a HEAT-compatible Ubuntu Trusty Tahr image will be provisioned to host the application and execute an UCD component process on:
The UCD application is called “MTM” composed of a single “mtm.web” component with a component process named “deploy“.
Log in as a user defined in the OpenStack realm and click “New..” in the Blueprints page. Give the blueprint a name, select “BluePrint” for Type and click Save.
Drag and drop the “private” Network resource from the Network drawer of the palette on the right onto the blueprint. Then drag and drop the “Ubuntu-14.04.x86_64” Compute resource onto the private network element, so the blueprint now looks like this.
Next, to have a floating IP address allocated when provisioned, click the “IP” icon at the bottom right of the Ubuntu compute resource. The instance will also need to have security rules assigned so drag and drop the “default” security group from the Security drawer on to the compute resource.
Save the blueprint. At this point the blueprint has enough information in it to be able to provision an environment from it, though it will have nothing from the UCD application/component on it. We won’t provision until we’ve added the UCD bits to it but clicking the Provision… button will get UCDP to prompt for any missing property values ( marked TODO in the Provision dialog).
Notice that various properties for the selected resource are displayed in the Properties drawer on the left, some of which take values from parameters (flavor, key_name) while others (Image, Name) are hard-coded.
By way of an example, to externalize the hard-coded Name property (which determines the instance name when provisioned) click the Set Property icon, give the property a name and click Create.
Now clicking Provision… will add a prompt for the “server_name” property.
Now let’s add the UCD component to be deployed to this compute resource and specify the component version to deploy . Drag and drop the “mtm.web” component from the Component drawer onto the compute resource, click the Edit icon for the Version property and replace “TODO” with ‘1.0‘. My servers take a while to provision so I also increase the Agent Timeout property to give the UCD agent enough time to be installed and started.
We’re almost done. We need to specify the name of the UCD application for which the new environment will be provisioned and the name of the component process to run on deployment. This is done in the Source view of the blueprint.
Select the Source tab and in the “mtm.web_sw_config” section the value of the component_process property needs to match the component process to be invoked. In the “resource_tree” section, change the value of the application property from TODO to “MTM” (quotes included).
Notice that with the cursor positioned on either line, the Set Property icon appears, allowing either of these values to be externalized rather than hard-coded.
We’re now in a position to have UCDP create the new UCD environment, provision a new compute resource, install and start the UCD agent on it and deploy the “mtm.web” component on it. Before provisioning, a couple of items worth pointing out:
- the “install and start the UCD agent” bit is auto-magically done by the auto-magically added the bit of code in the the user_data section of compute resource being provisioned.
- the (unique) name for the installed agent is constructed in that user_data code using the template
One last optional step before provisioning is to use a configuration file for the property values so we can potentially use the same blueprint with different sets of values. To do this click New.., select “Configuration for OpenStack” for Type, select the new HelloWorld_ucd Blueprint, give it a name and click Save.
This will create an empty property file. To add the properties from the associated blueprint to it click Add . Then change the property values as required.
Now click Provision…, specify a name for the new environment , select the Configuration created above, and click Provision.
The blueprint is validated and if there are no errors UCDP connects to OpenStack and UCD to begin provisioning. A couple of informational sliders show up at the top-right of the window and clicking the View Deployment Request link displays the provisioning in progress.
Looking at the Instances page on OpenStack Horizon shows the new instance being created.
Navigating to the UCD Resources->Agents page shows the place-holder for the UCD agent on the new server waiting to be provisioned.
And last but not least the UCD Environments page for the MTM application shows the state of the new environment.
Et voilà : a from-scratch Hello World UCDP + OpenStack + UCD example.
- I used a graphical editor to do most of the HOT creation and editing, with an “intelligent” text editor still available to work directly with the HOT source. In Cooking up deployments on stacked clouds I used my favourite text editor (no names mentioned:-) to edit the YAML HOT. In UrbanCode Deploy with vSphere and Chef I cooked up my own XML “blueprint”.
- I don’t need the UCD process to create a new HEAT stack. Once the blueprint is designed UCDP takes care of all the HEAT interactions. Note that in both previous posts UCD (rather than UCDP) drives everything and that’s a slightly different scenario using the process described in Provisioning environments from IBM UrbanCode Deploy , a process I will look at in a subsequent post.
- I don’t need the UCD process to “Install Agent and create resources”. UCDP does all of that for me, plus taking care of creating the environment, resource group and putting the agent resource in the right place.
So coming up are posts on Provisioning environments from IBM UrbanCode Deploy and an Amazon EC2 Hello World.
To finish though, a slight aside that relates to my liking for cool names for techie stuff. This time it’s the name for the 14.04 Ubuntu LTS: Trusty Tahr. My personal contact with the Nilgiri Tahr dates back to, well, a few months after my birth, when my folks lugged me up the mountain to Munnar. They still live there, I spent big chunks of my childhood there and go back at least every couple of years. In particular we would go to Rajamala, which besides being a haven for the Tahr, is (or was) a secret and magical trout fishing location, where Dad taught us the art of fly-fishing when I was but a pup. Here’s a picture of one close encounter (Mum) with a Tahr.