Example of a web application deployment

This topic describes a simple example to help you get started using the software quickly. The example defines the deployment for a basic web application to explain what you need in your environment to support the software, and provides the basic steps for a quick start.

Example scenario

You have a web application to be deployed, consisting of a WAR file and an SQL file:

Application structure.png

The current environment consists of the following elements:

  • A shared, operational environment
    • Jenkins build server for building the application
    • Database server for hosting internal applications
  • A test environment
    • MySQL database server
    • JBoss server that hosts the web application
  • A production environment
    • MySQL database server
    • JBoss server that hosts the web application

The following diagram illustrates this environment:

OpsTestProdEnv.png

Installing the deployment server

You add a computer for the deployment server and install the BMC Varalogix Q Deployment Automation software. The shared, operational environment now includes the deployment server, and the target computers in the test and production environments are running a BMC Remote System Call Daemon (RSCD) agent, as shown in the following figure:

OpsDepl.png

Post-installation configuration

After installation, you configure the system for deploying the web application. A complete deployment consists of the following parts:

  • The application package (what you will deploy): For a package definition, you create references that identify all the source files and other contents of the package, and you identify where to find those files and other contents by defining the servers where the contents reside.
  • The topology (where you will deploy):
    • First, you define templates that represent the services you are using in the application, like JBoss or SQL, and then define channels to link those services with a specific server. This enables a service to perform its processing correctly for the given server platform.
    • Next, create environments to contain the channels. Think of the environment as the collection of all services that your application needs to run. You can define an environment around a business stage or function, such as QA, Staging, Production, and so on, or around clusters of similar servers like database or web servers.
    • Last, define routes for the environments. A route is a business model concept: it connects environments in a sequence, with at least one environment per route. This enables you to model your business flow, such as the application development flow from QA to staging to production, and to control the movement from one stage to the next.
  • The deployment process (how you will deploy):
    • First, you create processes that define the activities needed to process the package contents. For example, activities for processing a WAR file could include copying a file or stopping and restarting a service.
    • Next, you add triggers to the processes that determine when to initiate a step. For example, you could set a trigger to confirm that all source files are in place before starting the deployment.

When you have defined all of these parts, you are ready to create a specific version of your package (an instance) and deploy it.

To define the application package (what you will deploy)

  1. Add a server definition for each computer in the network (see Managing-servers).
     Server definitions connect the deployment server to the target computers that provide the components for package instances and to the computers that deploy package instances. For each server, specify the host name and select the NSH agent for communication.
  2. Define a package, which is the container for your application (see Packages and Creating-and-viewing-package-or-repository-instances):
    1. Give the package an appropriate name (such as "New Web App").
    2. To the new package, add a reference for each application component. The reference defines the server name and path to each component (in this case, the WAR file and the SQL file). When you enter the URI, use the appropriate format for your platform (for example, file:///tmp/sample.htm for UNIX or file:///C:\Temp\sample.htm for Windows).
  3. Create an instance from the new package (see Packages).

Tip

By creating your instance now, you can ensure that the system has imported all data into the package and confirm that you have all the right parts for a deployable entity.

To define the topology (where you will deploy)

The topology defines the targets for the deployment and any dependencies. It represents the business infrastructure.

  1. Create a channel template.
    A channel is a logical target that represents a service, such as IBM WebSphere or Apache Tomcat. Templates enable you to organize according to service categories, such as templates for all WebSphere systems, JBoss, and SQL. Ultimately, you will want to create a template for every action pack (group of actions).
    1. Give the template an appropriate name (such as JBoss).
    2. Select an appropriate action pack, such as JBoss, for the template.
    3. Enter the root directory, which defines the directory level for channel access (for example, /var/www or C:\apache\htdocs.
  2. Create channels based on the previously defined channel templates.
     Channels correspond to servers, so you need one channel for the database and one for the web server. Channels are only outbound. Incoming data always goes to the deployment server and always deploys to logical endpoints. Channels associate those logical endpoints to the physical targets.
  3. Create environments and add the channels to them.
     Environments define a relationship between logical endpoints (channels), such as between a database and web server. Packages are targeted to an environment. You need an environment for test and one for production, with each environment containing a database channel and a web server channel.
  4. Create routes, and add the environments to them.
     A route connects environments in a sequence, with at least one environment per route. If multiple environments are in a route, you can choose the order of progression through each, and you can allow decision points at each step to control promotion to the next step. An application might have multiple routes through a test and a production environment.

You now have your topology in place, modeling your physical infrastructure around your business model.

To define the deployment process (how to deploy the application)

Create the deployment processes that actually does the work, using the action library to define the processes. You can create different types of processes by defining the activities and triggers associated with them.

Activities are basic building blocks with parameters that enable them to be reused in different environments. They represent single execution steps or commands within the deployment, such as sending a file or suspending deployment.

  1. Create a deployment processfor each type of package content, and define its activities. You need processes for the WAR file and the SQL file:
    1. The WAR file process could include “send content” commands to copy the file, then “invoke action” commands to stop and restart a service.
    2. The SQL file process could include commands that run the database command-line utility to process a script for applying the SQL file to the database.

    3. Add triggers to the processes. A process has one or more triggers, which determine if or when the process deploys. For example, you could create triggers for the deployment process that ensure that the content is in place before deploying. You need a trigger for the WAR file process and one for the SQL file process.

      Tip

      Triggers have a pattern and a template. For a given channel, the template contains a pattern that the system can use, for example, to search for a matching file name. An environment could have channels that are never triggered.

  2. Deploy the package to the route. In the deployment launchpad, drag and drop the package onto the route to create an instance and then deploy it automatically. See Using-the-launchpad.
    1. Examine the logs (red and green lights) to find any deployment problems. For more information, see Viewing-deployment-results.
    2. When you are satisfied with that step, you can promote the deployment to the next environment (for example, from testing to staging).

When you are satisfied that everything works as planned, you can create a schedule to run the deployment step on a regular basis. For more information, see Creating-and-using-deploy-schedules.

 

Tip: For faster searching, add an asterisk to the end of your partial query. Example: cert*