Migrating the Account Management environment to test
Your development efforts for the Account Management application will now conclude so you are ready to begin testing on the environment. We propose the following goals for the migration:
- The custom nodes should each run on their own hosts and not be collocated with the deployment manager.
- The application binaries should be retrieved from a different repository.
- The data source should be configured to refer to a different database instance.
The changes start by going to the patterns page and selecting the Account Management Cluster — Development pattern you created previously. Clone this pattern to create a new pattern called Account Management Cluster — Test and then navigate to the pattern editor page for the new pattern.
Once in the pattern editor, remove all of the script packages from the deployment manager part. You will be adding some of the script packages back, but you need to make sure you add them in the correct order.
Next, set up the new topology by dragging and dropping a custom node from the part list on the left-hand side to the canvas on the right. The count for the custom node part increases from one to two.
Now you add the script packages back to the deployment manager part. This time start by adding the Add IBM HTTP Server node script package that ships on the appliance. This script package establishes an IBM HTTP Server in the same virtual machine as the deployment manager, thus allowing you to conserve resources in your test environment. Finally, add back the script packages to install the Account Management application and create the necessary DB2 data source.
Figure 13. The new test pattern
WebSphere CloudBurst invokes script packages in the order that they appear on a pattern part. In this case, it is important to create the IBM HTTP Server instance before installing the application since it allows the application to include the server among its deployment targets, thus allowing requests for the application to route through our IBM HTTP Server instance.
The editing is not complete yet because you need to set up a WebSphere Application Server cluster. In this case though, you will not need a script package. Since you are using custom node parts, you can leverage the ability to define clusters as an advanced option for the pattern. To do this, click Advanced Options and select the Define clusters option.
Figure 14. Defining a WebSphere Application Server cluster
As a result of selecting this option, WebSphere CloudBurst will automatically create one or more WebSphere Application Server clusters during deployment of this pattern. You will provide the configuration information that tells WebSphere CloudBurst how many clusters you want and how many cluster members you want to create on each of your custom nodes. This is done either in the pattern or during deployment.
After configuring the pattern to include WebSphere Application Server clusters, you are done with the required changes; click the Done editing link to return to the pattern detail page. At this point, you can optionally lock the pattern. You are ready to deploy.
The deployment is slightly different from last time since your pattern contains two parts. When configuring the deployment manager part for deployment, you still need to provide the necessary configuration for the application installation and data source creation scripts. In this case, change the values for this configuration data to reflect the appropriate values for your test environment.
Figure 15. New configuration data for test environment
In particular, change the location of the application binaries, the database username, and the database host values (but you could have changed any values necessary to ensure a successful deployment into our test environment).
Unlike the previous deployment, you do not need to provide information to create managed nodes in the cell because you included custom node parts in your pattern. As a result, WebSphere CloudBurst will automatically create the nodes and take care of federating them into the cell. You still have to provide information about the WebSphere Application Cluster you want to create: The only difference is that in this deployment, WebSphere CloudBurst will create the cluster instead of you having to do it, including a script package to carry out that configuration action.
Figure 16. Configuring the WebSphere Application Server cluster
The values in Figure 16 result in the creation of a single cluster which contains one member on each node. In this case, that means your WebSphere Application Server cluster will have two members because your pattern contains two custom node parts.
In this pattern, you also have to configure the custom node parts before you deploy. There are no script packages on this part, so all you need to do is provide password information. Deploy the pattern by clicking the OK button on the deployment dialog. Again, this takes you to the Virtual Systems page and when the deployment process is complete and the virtual system is in the started state, you login to the WebSphere Application Server administration console just as you did last time. The only real difference for this deployment besides the altered application and data source configuration, is that the custom nodes exist on different hosts than the deployment manager.
Figure 17. Node listing for WebSphere Application Server cell
The CloudBurstNode and CloudBurstNode1 nodes shown in Figure 17 were created from the two custom node parts in our pattern. The CloudBurstNode0 and cbmv-112.rtp.raleigh.ibm.com-node nodes represent the deployment manager and IBM HTTP Server instance respectively.
The key point in the migration from your development environment to your test environment is not the differences though — the real key is that the net result of these two deployments is the same. In both environments, the Account Management application runs on a WebSphere Application Server cluster and that application has access to a data source for a DB2 database. Further, you achieved this migration by simply making a few changes in a drag-and-drop interface and providing a very small amount of deploy time configuration.
The migration from one environment to the next took just a matter of minutes.