Deployment Lifecycle Scripts
Scripts can be called at multiple points during a deployment. The following images depict the execution process for each service workflow:
Node Initialization Workflow
External Initialization Workflow for VM tiers.
See External Service for additional context.
External Initialization Workflow
For non-VM tiers like application tiers. See External Service for additional context.
Node Reboot Workflow
Triggered from either the VM Reboot or Suspend/Resume action in the Deployments page.
The Suspend script, introduced in CloudCenter 4.8.0 is similar to the Resume script that is triggered when the node is suspended.
Node Update Workflow
Triggered by a VM scaling action or a reboot on other VMs.
Node Terminate Workflow
Requires all nodes to be running in order for the application to be powered off.
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
- 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 Methods||Description||Additional Details|
Points to a repository hosted in the external site (such as HTTP or Amazon S3).
|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. 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.
|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:
- Region Level: See
- Service Level: See External Service > External Initialization Scripts.
- Application Tier Level: See Service Lifecycle Actions.
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).
|Script||Level of Script|
|Script Download Location||User Running Script||Script Run Location|
|Pre-VM Start||Region||Same as Script Download Location|
|Install||Service||root||Same as Script Download Location|
|Pre-VM Start||Service||Same as Script Download Location|
|Initialization Script||Application||Agent user (typically cliqruser)||Same as Script Download Location|
|Agent user (typically cliqruser)|
|VM Pre-provision Script||Same as Script Download Location|
|VM Pre-initialization Script|
|VM Post-start Script||Application (External Initialization)||Same as Script Download Location|
|VM Pre-terminate Script|
|VM Post-terminate Script|
|Pre Migrate Script||Application||Agent user (typically cliqruser)||/home/cliqruser/|
|Post Migrate Script|
|Pre Upgrade Script|
|Post Upgrade Script|
The dynamically-generated VM password is injected as part of the lifecycle action and made available for use inside External scripts.
- Windows deployments: The password for cliqr users is available in the cliqrWindowsPassword environment variable in the pre-Init, post-start, pre-terminate, and post-terminate phases.
- Linux deployments:
- The user name is available in the sshUserName environment variable
- The SSH private key is available in the sshKey environment variable.
- The SSH public key is available in the sshPublicKey environment variable
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 Model Using Application Packages.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
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. 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:
$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:
- No labels