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
The following image shows the node initialization workflow.
External Initialization Workflow for VM Tiers
See External Service for additional context. The following image shows the external initialization workflow for VM tiers.
External Initialization Workflow
For non-VM tiers like application tiers. See External Service for additional context. The following image shows the external initialization workflow.
Node Reboot Workflow
Triggered from either the VM Reboot or Suspend/Resume action in the Deployments page. The Suspend script is similar to the Resume script that is triggered when the node is suspended. The following image shows the node reboot workflow.
Node Update Workflow
Triggered by a VM scaling action or a reboot on other VMs. The following image shows the node update workflow.
Node Terminate Workflow
Requires all nodes to be running in order for the application to be powered off. The following image shows the node terminate workflow.
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 as displayed in the following screenshot:
Node Initialization and Clean Up as displayed in the following screenshot:
External Initialization (see External Service for additional context) as displayed in the following screenshot:
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 Application Using App Package|
|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.
Lifecycle Action Script Definition
This section explains 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 External Lifecycle Actions Settings.
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).
The following table identifies the level and details required to define and use each script.
|Script||Level of Script|
|Script Download Location||User Running Script||Script Run Location|
|Pre-VM Start||Region||External script execution engine|
|Same as Script Download Location|
|Install||Service||root||Same as Script Download Location|
|Pre-VM Start||Service (external)||External script execution engine|
|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||Application (External Initialization)||External script execution engine||cliqruser||Same as Script Download Location|
|VM Pre-initialization Script|
|VM Post-start Script|
|VM Pre-terminate Script|
|VM Post-terminate Script|
|Pre Migrate Script||Application (migration and upgrade)||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.
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 download a file or folder from the repo)
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
The Request Utility, for both Linux and Windows requires that the repo server you refer to use the HTTP or HTTPS protocol.
In earlier releases, users were able to use special characters in the userenv file. However, sourcing files with these special characters caused issues in scripts that used the userenv file.
Special characters like pipe or double quotes are configured with escape sequences that use single quotes, not double quotes.
You can successfully source userenv files that contain these special characters.
Accessing Files from a Configured Repo
While you can use the File in Package option to model an Application Using App Package, this option bundles the required files into a zip file that you can download.
Alternately, you may also opt to download something from inside a script that is stored in a configured repository. For example, you have configured a file in a repository called MyFiles for your lifecycle scripts using the HTTP protocol and have it password protected, as well as configured a nodeInit script called myscript as follows:
Repo: MyFiles, path:/myscript.sh
Later, you may need another user to download a file from the same MyFiles repo without knowing the credentials or the contents for either agent-based and external actions.
The following table provides usage details on accessing a file from a configured repository.
download $<relative folder path on repo> <node service step>
download <path_on_repo>/<filename.txt> <initScript/ prestart/ poststart/ prestop/ poststop>
download auto/record_results.sh initScript
The file is downloaded to /opt/remoteFiles
backupFile $<relative file path on repo> $<location of local file to be backup >
|backupFile <path_backup_folder_on_repo>/<backup_filename.txt> /tmp/test_backup.txt|
backupFile $CliqrDeploymentId/dbbakup.sql /tmp/dbbakup.sql
restoreFile $<relative file path on repo>
|restoreFile <path_backup_folder_on_repo>/<backup_fliename.txt>||restoreFile $migrateFromDepId/wpbkup.zip|
Parameters and Configuration Files
Pre-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 Workload Manager-Defined Parameters or Parameter Substitution), you may need to modify the service Configuration Files to reflect the correct property defined in the relevant parameter.
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
Workload Manager executes each pass in order, picking up where it left off each time. Consider the following sample scripts:
The #!CliQrReboot: Header
The #!CliQrReboot: header to the /tmp/.cliqrRebootResumeInit file – Once the agent detects the #!CliQrReboot: header, it resumes after a reboot in the service lifecycle flow depending upon the context set in the header. You can control the resume flow after reboot by adding the resume context header to the /tmp/.cliqrRebootResumeInit file.
For example, #!CliQrReboot:Current as a header allows you to resume the current lifecycle action. Similarly, #!CliQrReboot:Next to resume to next step in the lifecycle actions and #!CliQrReboot:Deploy to resume from deploy service lifecycle actions. Consider the following sample scripts:
The following sample Linux script reboots twice and resumes the same lifecycle action after the reboot. The resume context is only supported in a deployment's deploy flow. It is not supported during the deployment suspend, resume or terminate flows.
The following Windows sample script takes two parameters (action and reboot):
To use the .#!CliQrReboot: header, you must use ASCII encoding – otherwise, the agent will not be able to pickup the required directives.
However, if you are not using the .#!CliQrReboot: header, you can use other encoding as well.
- No labels