Deployment Lifecycle Scripts

Script Workflow

Scripts can be called at multiple points during a deployment. The following images depict the execution process for each service workflow:

Node Initialization Workflow
Node init workflow 4.6

External Initialization Workflow for VM Tiers

See External Service for additional context.
External Initialization - VM Based

External Initialization Workflow

For non-VM tiers like application tiers. See External Service for additional context.
External Service -App Tier

Node Reboot Workflow

Triggered from either the VM Reboot or Suspend/Resume action in the Deployments page.
Node reboot 46

Node Update Workflow

Triggered by a VM scaling action or a reboot on other VMs.
Node update 46

Node Terminate Workflow

Requires all nodes to be running in order for the application to be powered off.

4.8 Node Terminate Flow

Applications Impacted by the Workflow Change

As the the node terminate workflow changed in CloudCenter 4.8.0.1 (prior to CloudCenter 4.8.0.1, Node Cleanup occurred prior to Service Pre-Stop, effective CloudCenter 4.8.01, Node Cleanup occurs after Service Post-Stop), you may have app profiles that use CloudCenter 4.8.0 and earlier and may need to understand which profiles are impacted by this change.

To view application profiles that are impacted by this workflow change, follow this procedure.

  1. Login to the CCM server.

  2. Issue the following command:

    psql -U cliqr -d cliqrdb
  3. Execute the following query:

    SELECT DISTINCT name FROM all_templates WHERE template_id IN
    (SELECT parent_template_id  FROM child_job_templates WHERE template_id IN
    (SELECT template_id FROM
    (SELECT a.template_id,t."paramName",t."defaultValue" FROM all_templates a
    CROSS JOIN LATERAL
    json_to_recordset(a.app_param_spec_text::json) AS t("paramName" text,"defaultValue" text)
    WHERE ("paramName" LIKE '%PreStopAction' OR "paramName" LIKE '%PostStopAction'
    AND "paramName" NOT LIKE 'cliqrExternalPreStopAction' AND "paramName" NOT LIKE 'cliqrExternalPostStopAction')
    AND (a.leaf_level = true) AND ("defaultValue" <> '') AND (a.cleanup_script <> '')) AS temp)) ORDER BY name; 

    All application profiles that are impacted by this workflow change are displayed in response to this query.

Script Categories

Service lifecycle actions can be divided into two categories:

  • Service Scripts: Each service script corresponds to a Service Lifecycle Actions. See Service Administration for additional context. Once the root admin configures the services and makes it available to users, users can access the service and add on their own application scripts to each service or tier as required.

  • Application Scripts: Users specify each application script when modeling an application or application profile. The New Application and New Application Profile sections provide more details on these scripts.

Using Scripts in Application Profiles

While the Topology Modeler > Services tab (or palette) allows the root admin to add on the required services for each user or tenant, the Topology Modeler > Properties tab allows users to initialize, clean up, or resume the app tier. The following images highlight the application script configuration location in the Topology Modeler's Properties tab.

  • Service Initialization Pre-Start and Post-Start:


  • Node Initialization and Clean Up:
  • External Initialization (see External Service for additional context):
  • Similarly, you will also find the Migration and Upgrade in the configuration location in the Topology Modeler's Properties tab.

Script Source Details

The different script sources are explained in the following table:

Sourcing MethodsDescriptionAdditional Details
Repositories

Points to a repository hosted in the external site (such as HTTP or Amazon S3).

See Share Artifact Repositories

File in package

The script resides in the Application Content Package.

See the Application Content Package section below
URL or Command

A URL Points to a file that is downloaded and executed by the Management Agent. This URL can point to any location relevant to this service.

A command (shell or powershell direct commands) is used to run all service-related actions. For example: apt-get install foo, or echo hello, or rerun cliqr, and so forth.

The script option does not work when using the command line. Instead, use the URL option and add a script URL.

See Parameters and Macros

Script from bundle (for Service Lifecycle Actions)

The script path is a relative path inside the extracted folder (/usr/local/osmosix/service).

The name of the bundle directory must match the name displayed in the Identifier field. This step is essential – the service cannot be created if the name or the relative path differs.

This action is only available if the service points to a bundle Location.

See Bundle Store

Lifecycle Action Script Definition

The following table identifies the level and details required to define and use each script.

See the following sections for additional information on the lifecycle action script definition at each level:

All scripts are executed from the current script directory and allow multiple scripts to be issued at the same time.

Script Download Owner Permission

The download owner permission for all scripts at all levels is root (-rwxr-xr-x).

 ScriptLevel of Script

Definition

Script Download LocationUser Running ScriptScript Run Location
Pre-VM StartRegion



  • /opt/remoteFiles/cliqr_local_file/
  • C:\temp\remoteFiles\cliqr_local_file\



  • root
    (CloudCenter 4.6.x)
  • cliqruser
    (CloudCenter 4.7 and later)




Same as Script Download Location




Pre-VM Init
Post-VM Init
Pre-VM Init
Post-VM Init
InstallService







  • /usr/local/osmosix/service/{serviceName}/
  • C:\program files\osmosix\service\{serviceName}\
root







Same as Script Download Location
Configure
Deploy
Start
Stop
Restart
Reload
Upgrade
Clean Up
Pre-VM StartService
  • /opt/remoteFiles/cliqr_local_file/
  • C:\temp\remoteFiles\cliqr_local_file\
  • root
    (CloudCenter 4.6.x)
  • cliqruser
    (CloudCenter 4.7 and later)
Same as Script Download Location
Pre-VM Init
Post-VM Init
Pre-VM Init
Post-VM Init
Initialization ScriptApplication
  • /opt/remoteFiles/initScript/
  • C:\temp\remoteFiles\initScript\
Agent user (typically cliqruser)Same as Script Download Location
Cleanup Script
  • /opt/remoteFiles/cleanupScript/
  • C:\temp\remoteFiles\cleanupScript\
  • root
    (CloudCenter 4.6.x)
  • cliqruser
    (CloudCenter 4.7 and later)
Resume Script
  • /opt/remoteFiles/resumeScript/
  • C:\temp\remoteFiles\resumeScript\
Agent user (typically cliqruser)
Pre-Start Script

Application

(Service Initialization)






  • /opt/remoteFiles/cliqr{serviceName}PreStartAction/
  • C:\temp\remoteFiles\cliqr{serviceName}PreStartAction\
  • root
    (CloudCenter 4.6.x)
  • cliqruser
    (CloudCenter 4.7 and later)
/usr/local/jetty/
Post-Start Script
  • /opt/remoteFiles/cliqr{serviceName}PostStartAction/
  • C:\temp\remoteFiles\cliqr{serviceName}PostStartAction\
Pre-Stop Script
  • /opt/remoteFiles/cliqr{serviceName}PreStopAction/
  • C:\temp\remoteFiles\cliqr{serviceName}PreStopAction\
Post-Stop Script
  • /opt/remoteFiles/cliqr{serviceName}PostStopAction/
  • C:\temp\remoteFiles\cliqr{serviceName}PostStopAction\
VM Pre-provision Script
  • /opt/remoteFiles/cliqr_local_file/
  • C:\temp\remoteFiles\cliqr_local_file\
Same as Script Download Location
VM Pre-initialization Script
VM Post-start ScriptApplication (External Initialization)


  • /opt/remoteFiles/cliqr_local_file/
  • C:\temp\remoteFiles\cliqr_local_file\
  • root
    (CloudCenter 4.6.x)
  • cliqruser
    (CloudCenter 4.7 and later)
Same as Script Download Location
VM Pre-terminate Script
VM Post-terminate Script
Pre Migrate ScriptApplication
  • /opt/remoteFiles/preMigrateScript/
  • C:\temp\remoteFiles\preMigrateScript\
Agent user (typically cliqruser)/home/cliqruser/
Backup Script
  • /opt/remoteFiles/backupScript/
  • C:\temp\remoteFiles\backupScript\
Restore Script
  • /opt/remoteFiles/restoreScript/
  • C:\temp\remoteFiles\restoreScript\
  • root
    (CloudCenter 4.6.x)
  • cliqruser
    (CloudCenter 4.7 and later)
/usr/local/jetty/
Post Migrate Script
  • /opt/remoteFiles/postMigrateScript/
  • C:\temp\remoteFiles\postMigrateScript\
Pre Upgrade Script
  • /opt/remoteFiles/upgradeScript/
  • C:\temp\remoteFiles\upgradeScript\
Upgrade Script
Post Upgrade Script
Rollback Script

Utility Files

Users can also include utility files in scripts.

The following are some examples of utility files that can be sourced by Linux users:

  • Environment Variables: /usr/local/osmosix/etc/userenv

  • OS Information: /usr/local/osmosix/service/utils/os_info_util.sh

  • Service Install Utility: /usr/local/osmosix/service/utils/install_util.sh

  • Configuration Utility: /usr/local/osmosix/service/utils/cfgutil.sh

  • Request Utility: /usr/local/osmosix/etc/request_util.sh (send request to agent to get things done)

The following are utility files that can be sourced by Windows users:

  • Environment Variables: c:\temp\userenv.ps1

  • Utility Information: c:\Program Files\osmosix\etc\cliqr.ps1
  • Request Utility: c:\Program Files\osmosix\etc\request_util.ps1

Parameters and Configuration Files

CloudCenter-Defined Parameters are also available for use in application profiles to automate jobs without writing extensive scripts (examples include timestamp, dynamically-generated IP address, private IP address, IP address of a tier, environment variables, automation policy parameters, number of nodes in a cluster, deployment name, and so forth).

Sometimes, you may have a custom parameter already defined in a particular service that you do not want to set in the application profile. Instead, you want to leave it to your end users to Substitute a Parameter or use Troubleshooting Parameters when they model application profiles or deploy applications.

If you use parameters (either CloudCenter-Defined Parameters or Substitute Parameters), you may need to Modify the Service Configuration Files to reflect the correct property defined in the relevant parameter.

Application Content Package

Scripts for each VM and  its associated scripts can be bundled into a single ZIP file and referenced as an application content package in the application profile. This packaging allows for easier management of the scripts as well as the ability to enable scripts to refer to each other using relative paths without having to contain explicit download logic. See Model Using Application Packages.

Internal Reboot During Node Initialization

The reboot referenced above is initiated externally when a user reboots the VM, or issues a Suspend/Resume command, or a direct OS reboot command. This reboot usually happens after the node is fully initialized and running. 

Another reboot scenario is the internal reboot – when the reboot is part of node initialization process. This reboot is initiated by the management agent. Once the agent detects the .cliqrRebootResumeInit flag, it performs a backup and reboots itself.

You can setup multiple stage node init scripts by using appropriate flow-control logic and manipulating the following files:

  • /tmp/.cliqrRebootResumeInit 
  • $OSMOSIX_PROD_HOME/.cliqrRebootResumeInit

    $OSMOSIX_PROD_HOME defaults to /usr/local/osmosix

CliQr executes each pass in order, picking up where it left off each time. Consider the following sample script:

#!/bin/bash
# Make sure to source these files to pick up all the CliQr environment variables.
. /usr/local/osmosix/etc/.osmosix.sh
. /usr/local/osmosix/etc/userenv
  
# After triggered reboot, CliQr agent generates file $OSMOSIX_PROD_HOME/.cliqrRebootResumeInit
# with prior state from /tmp/.cliqrRebootResumeInit
 
# If this file DOES NOT exist, it means that this is the first pass through the script.
# The CliQr agent has not previously triggered a reboot and created this file.
if [ ! -e $OSMOSIX_PROD_HOME/.cliqrRebootResumeInit ];
then
    # Node was not rebooted already by CliQr nodeInit. First pass through this script.
 
    # Triggers a reboot after the script exits, then this file is deleted.
    # "Step 2" will now appear in $OSMOSIX_PROD_HOME/.cliqrRebootResumeInit
    echo "Part 2" > /tmp/.cliqrRebootResumeInit
else
    # Node was rebooted on the last pass through the script.
    # Read in prior state from file generated by CliQr
    step=`cat $OSMOSIX_PROD_HOME/.cliqrRebootResumeInit`
 
    # Check the prior state to continue with the next part of the script.
    case $step in
        "Part 2")
            # Triggers a reboot after the script exits, then this file is deleted.
            # "Step 3" will now appear in $OSMOSIX_PROD_HOME/.cliqrRebootResumeInit
            echo "Part 3" > /tmp/.cliqrRebootResumeInit
            ;;
        "Part 3")
            # Don't write to /tmp/.cliqrRebootResumeInit this time. CliQr will not reboot.
            # Script exists, and node init is complete.
            ;;
    esac
fi

 

 

 

  • No labels