Service Administration


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 Supported 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.

Service Clustering

Workload Manager allows you deploy multiple instances of a service within a tier when that service is stateless, such as a base OS service or a web service. 

The minClusterSize and maxClusterSize are system-defined parameters for services (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, specify the information in a static parameter. See Parameter Substitution and Using Parameters 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,, 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 Applications 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
> >(tee -a /usr/local/osmosix/logs/service.log) 2>&1
"Executing service script.."
main entry
$1 in
install -y tomcat tomcat-webapps tomcat-admin-webapps
                  if [ -z $cliqrWARFile ]; then
                                    exit 0
                  cp $cliqrWARFile
                  systemctl start tomcat
                  systemctl stop tomcat
                  exit 127

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,

  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
Terms & Conditions Privacy Statement Cookies Trademarks