CloudCenter 4.8 has reached End of Life (EOL) as of November 14, 2018. See End of Support Notices for additional context.

Service Administration


A service is a mid-tier building block for an application. The concept of services is natural to the CloudCenter platform.  The concept of services like Tomcat, NginX, MongoDB, and so forth existed within the internal CloudCenter platform and exposes them via the Topology Modeler. The list of supported services are available in the Services section.

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.

See the following pages for additional information:

Custom Service Clustering

CloudCenter 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 CloudCenter-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 CloudCenter, 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 the CCO. For example, when the CCO 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: Use a commonly mounted storage service (for example, NFSCephFS). 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 Storage as a Service 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 an Application Profile.

In the simplest case, all lifecycle actions are contained in a single script. The following example uses Bash.

  1. To start, define install, deploy, start, and stop.
  2. Service parameters are passed to this script through CloudCenter.
  3. The parameters are defined as part of the Define a Custom Service process and accessed in the scripts through an environment variable.
  4. Set the environment variable in the file /usr/local/cliqr/etc/userenv file. See Deployment Lifecycle Scripts > Utility Files  and CloudCenter-Defined Parameters > Environment Variables for N-Tier Deployments for additional details.
  5. Use a parameter to define a .war file to deploy – $cliqrWARFile. As the war file is optional, be sure to define it.

    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
  6. Name this file, for example, SampleService and make it executable (chmod 755).
  7. Add it to a directory named, for example, tomcatCentOS7.
  8. Zip this file and name it, for example,
  9. Upload to a repository accessible in CloudCenter.
  10. Use this file when defining the service within CloudCenter.

    The Service ID in CloudCenter must match the name used here – tomcatCentOS7.

Export Application Scripts

See New Application Profile for additional context.

  • No labels
Terms & Conditions Privacy Statement Cookies Trademarks