Service Administration

Overview

A service is a mid-tier building block for an application. The concept of services is natural to the Workload Manager. The concept of services like Tomcat, NginX, MongoDB, and other OOB Services is exposed via the Topology Modeler. This section discusses the services framework that is available at the administrative level.

The Services Framework

The Services Framework enables enterprises to create and add their own services to the Service Catalog and make them available in the Topology Modeler. Once the enterprise defines the service, the same definition can be used across applications.

Custom Service Clustering

Workload Manager allows you to group custom services into a cluster. Each custom service inherits properties of the group to which it was added. For example Tomcat6, Tomcat7 inherits properties of the Web Server group. Clustering is only available for certain services.

For any service to support clustering, you can explicitly specify the minClusterSize and maxClusterSize system-defined parameters (see Pre-Defined Parameters for additional context). The Web Server or OS service groups already inherit these parameters and you do not need to explicitly define the parameters.

Using Workload Manager, you can add or reduce the number of nodes within a clustered service.

Handling Information between Tiers

For a multi tier deployment, VMs for all tiers are launched in parallel. During the node initialization phase, every node is passed the IP address of all other nodes in the topology as environment variables by Workload Manager. For example, when Workload Manager passes the IP address of MySQL service to Apache, the scripts on the Apache service can access this IP address using a convention %[TierName]_TIER_IP%.

To share information (that may not be known prior to a deployment) between tiers, you have multiple options:

  • Static information: Specify the information in a static parameter. See Parameter Substitution and Using Parameters for additional context.

  • Dynamic information: For example, to pass the database schema name from the database tier up to an application tier, you can share information between tiers by using a mounted storage. See Understand Application Tier Properties for additional context.

Guidelines to Configure Service Scripts

Scripts is the most common method used to configure a lifecycle action is to use scripts. Ensure to adhere to these guidelines when configuring service scripts:

  • You can configure scripts in any language or format.

  • Add all agent lifecycle action scripts to the .zip file along with any required configuration files and use them together

  • Structure the .zip file to have a top-level folder containing all the files required for the service. You can also use sub-folders to organize the scripts and supporting files.

  • The top-level folder name must match the name provided for the Service ID when defining the service (for example, tomcat6.zip, where tomcat6 is the Service ID).

  • Define the Lifecycle Action script path is defined relative to its location in the .zip file.

  • Set the Access Link URL from within a script, be sure to configure the information when you Model Application Profiles.

In the simplest case, all lifecycle actions are contained in a single script. Service parameters are defined as part of the Custom Service Definition process and accessed in the scripts through an environment variables. See Deployment Lifecycle Scripts > Utility Files  and Pre-Defined Parameters > Environment Variables for N-Tier Deployments for additional details.

The following sample service script:

  1. Installs Tomcat web server
  2. If the environmental variable $cliqrWARFile is null, the script terminates; if not, the script moves the file referenced by the variable to a folder known by Tomcat web server.
  3. Provides the commands to execute at the time of VM start and VM stop.


Sample Service Script
#!/bin/bash
exec
> >(tee -a /usr/local/osmosix/logs/service.log) 2>&1
echo
"Executing service script.."
.
/usr/local/cliqr/etc/userenv
#
main entry
case
$1 in
    install)
                  yum
install -y tomcat tomcat-webapps tomcat-admin-webapps
        ;;
    deploy)
                  if [ -z $cliqrWARFile ]; then
                                    exit 0
                  fi
                  cp $cliqrWARFile
/usr/share/tomcat/webapps
        ;;
    configure)
        ;;
    start)
                  systemctl start tomcat
                  ;;
    stop)
                  systemctl stop tomcat
                  ;;
    restart)
                  ;;
    cleanup)
        ;;
    reload)
        ;;
    upgrade)
        ;;
    *)
                  exit 127
                  ;;
esac 

To use this script as the service script for a custom service named tomcatCentOS7:

  1. Make the script file executable (chmod 755).

  2. Zip the file and give it the same name as the service it will be used in; in this case, tomcatCentOS7.zip.

  3. Upload the zip file to a repository accessible to Workload Manager.

  4. In the Workload Manager Edit Service page for this service, for Agent Actions Bundle field, specify the repository location and the path to the zip file.

  5. Ensure that any environmental variables that require user input (in this case, $cliqrWARFile) are included as service parameters in the Edit Service page.

    The Service ID of your custom service must match the name of the service script bundle zip file, in this case, tomcatCentOS7.

Export Application Scripts

See New Application Profile for additional context.

  • No labels
© 2017-2019 Cisco Systems, Inc. All rights reserved