Deploying UrbanCode Deploy Blueprint Designer Cloud Applications Part 6 – Provisioning a Multiple Instance Blueprint
The ucd_blueprint_designer_test example stepped through in blog entries Parts 4 and 5 is good enough to explain blueprint design, the provisioning process, and to demonstrate that things are operational and connected properly. However, in the real world, application environments will consist of multiple VM instances and not be as simple as deploying a component with no artifacts that prints “Connected”. In Part 6, we are going to discuss how to provision a multi-component web application. The development example will deploy all the components onto a single instance development environment. Our production example will construct an environment consisting of the web application and app server on one instance connected to a database on another instance. Although both examples are still very simple, it is sufficient in demonstrating how to use blueprint designer to provision infrastructure and application components.
The JKE Banking Example
In UCD version 220.127.116.11 and later, another example program was added to the cloud agent installation package called JKE. The JKE Banking sample application is a fictitious financial services application that runs in WAS Liberty Profile and uses MySQL for a database. The application consists of a WAR component containing the application and a database component that installs and creates the database. The WAR application installs data into the database the first time it is started.
The sample application can be loaded into UCD using a script included in the cloud agent package installation. Navigate to installation_directory/ibm-ucd-patterns-install/agent-package-install/ and execute the following command replacing the values in red with your server name, port, and user credentials. You can either use token authentication or a username and password. Make sure you have JAVA_HOME set to JRE or JDK version 1.8.0
./install-jke-application.sh -s https://<ucd-server>:<ucd-server.port> -a <token>
Inside the exploded jke.war WAR directory in WEB-INF/classes is a database properties file called JKEDB.properties. It contains the data connection information for the jke.war application.
Figure 1 – JKEDB.properties Properties File
The application uses the properties in this file to dynamically build the database connection URL at runtime. The jke.war component, after loading into UCD, has a component environment property called JKE_DB_HOST set to localhost. In its component process the jke.war file is extracted, the properties file is modified to replace jdbc.hostname with the value of JKE_DB_HOST, and the exploded war file is zipped back up as a WAR file. The Update Property step configuration is shown below.
Figure 2 – Update Properties Step in jke.war Component Process
To better understand the steps that are coming, it is worth spending some time on your own looking at the four components that make up the JKE application – the component the component processes, the component artifacts, and component properties. Once you are comfortable with the UCD objects in play, proceed with the rest of this blog entry.
Provisioning a Development Environment
To represent a development environment we are going to place the entire application on one VM. Such a blueprint will look as follows. Use the Deployment Sequence in the Policies drawer on the right palette to set the order in which the components are deployed. Ideally we could deploy WAS Liberty Profile at the same time we are deploying MySQL Server but since we are provisioning to a t1.micro flavor, running two install processes might be to much for the VM.
Figure 3 – JKE-Development Blueprint
In the Blueprint, select the VM and change its key and name to jke-development. Next select each component and increase the Component Process Timeout. Set WAS Liberty Profile agent timeout to 750 and MySQL Server component timeout to 600 seconds. Set the jke.war component process timeout to 600. Again, ideally, we would be running the JKE Banking application on flavors of appropriate size and the timeouts may not need to be adjusted. Make sure to check the green check box to save the values. Save your blueprint.
Figure 4– Increase Component Process Timeout
Select the jke.war component. In the palette to the left, expand the Environment Inputs. You will see the Jke DB Host parameter. It is set to localhost. The parameter comes from the component environment property JKE_DB_HOST and can be overruled in the blueprint. This value is actually ok since the database is on the same instance with the app server and jke.war.
Figure 5 – JKE_DB_HOST localhost Value
Let’s provision the blueprint. In the provision dialog, remember to set the agent relay hostname, the flavor (t2.micro), the key, and the availability zone (us-east-1b). Save these settings as a configuration once configured in the GUI and you will able to apply the configuration the next time you provision.
Figure 6 – Single Instance Deployment
The application runs on port 9080 and the login is jbrown/jbrown.
Figure 7 – Single Instance Application
Provisioning a Production Environment
The development environment is good enough for developer testing but for higher order environments the full stack deployment is likely to be different and more interesting. QA and Production might use two instances – one for jke.war and app server and one for jke.db and database. We would also typically specify larger flavors but for this exercise we will keep it at t2.micro.
Before we begin, for this blueprint we are going to introduce the port. Set a component environment property for call JKE_DB_PORT with a default value of 3306.
Figure 8 – jke.war Component Environment Properties
Lets build the blueprint. It will look like the following.
Figure 9 – JKE-Production Blueprint
You will notice that Liberty Profile and MySQL Server are now being installed in parallel. If you recall, jke.war needs to know the IP or host name of the machine on which the database is running. But how does it know what that value will be since the DB instance does not yet exist? The Blueprint Designer provides that information through HEAT attributes returned by Amazon. Now instead of localhost we are going to get the IP of the database VM. Click on the jke.war component. Expand the Environment Inputs and click on the arrow next to localhost for the Jke Db Host.
Figure 10 – Set jke.war Environment Properties
A dialog will appear. Click on Attributes and select IP address for ’jke-database’.
Figure 11 – Select Database IP Address
The property in the palette will change and the blueprint source code will reflect the name of the attribute. Save your blueprint.
Figure 12 – Change to Database IP Address
You will see the Jke DB Port is available as well. For now leave the default value for the port. Unlike the JKE_DB_HOST parameter there is no equivalent attribute for the port. In my next blog post how to modify our example and set the port with a parameter.
The Blueprint Designer is able to acquire a number of Heat attributes from Amazon. For example, if you wanted to use host name of the VM instead of the IP you would use public_dns_name instead of first_address.
Figure 13 – Available Heat Attributes
The jke.db component will also need some parameters set. Select the jke.db component in the blueprint and go to its Environment Inputs. For the Db Endpoint Address we can use the same Attribute that we used for jke.war Jke Db Host. For the Db Name, Db Password, and Db User, click on their pencils and set them to JKEDB, password, and jke_user respectively. Click the green checkmarks to set the values. Save your blueprint and remember to do so often.
Figure 14 – jke.db Environment Inputs
When you provision, you should create a new Amazon configuration and add a value for Availability Zone 2 (since there is now a second VM). Set it to us-east-1b. You will also want to add the appropriate security groups to the 2 VMs so the URL can be reached on port 9080 and the database can be reached on port 3306. Finally, you may want to increase the agent timeout from 360 to 750 for both WAS Liberty Profile and MySQL Server and set the component process timeout for MySQL Server to 600 since there two downloads – one for each VM (not an issue if you are using a UCD installation in the cloud or flavors and network of adequate size and speed). The provisioning request will now show two instances created, the WAS Liberty Profile and MySQL Server being deployed at the same time, followed by jke.db, and then jke.war.
David J. Arnone
is an ALM and DevOps Architect specializing in IBM CLM and UrbanCode Deploy solutions and services. As a certified Rational CLM Architect, David joined Zilker Technology in January, 2017 and is part of the growing Zilker DevOps practice team.David Arnone. View more blogs by David Arnone
Don't miss out! Get updates on new webcasts, events, and blogs.