Service Lifecycle Actions

Overview

A service goes through various phases as it becomes operational. Service Lifecycle Actions allow enterprises to define a script or command that must be executed during different service lifecycle phases.

The root or tenant administrator can import and add services that are specific to their enterprise using the Services > Add Service function. The following screenshot shows this function.

See Custom Service Definition for additional context.

The type of lifecycle actions that may be defined for a service depend on the type of service as shown in the following table.

Service TypeVM with AgentVM w/o AgentExternal (no VM)Container
Lifecycle Action TypesAgent lifecycle actions,
External lifecycle actions
External lifecycle actionsExternal lifecycle actionsContainer Lifecycle hooks

Links to the individual lifecycle actions are specified in corresponding fields in the Edit Service and Add a Service pages.

Agent Lifecycle Actions

The Agent lifecycle actions are only available for services based on VMs with the Workload Manager agent installed. The following table describes the agent lifecycle actions.

UI Service ActionactionName API EnumerationDescription

Install

INSTALL

The install service phase is implemented when the node first comes up.

Similar to the image installation process, Workload Manager also abstracts all supported OOB Services into small, individual files made available through The CloudCenter Worker1 image. When you drag and drop a service (any supported or customer-defined service) from the Topology Modeler's Services tab into the Topology Modeler graphical interface, you are instructing Workload Manager to use this service to model or deploy your application. At this point, all service files (ZIP format), regardless of each being a OOB or Custom Service Definition, are automatically extracted (from their respective locations — either Package Store (repo.cliqr.com) or you own Artifact Repository to the /usr/local/osmosix/ directory. The ZIP file for each service contains the root folder. For example, when you use the Tomcat7 service, the extracted file contains a root folder called Tomcat7. This /usr/local/osmosix/Tomcat7 folder contains the scripts related to this service. Use this perspective accurately when you call additional scripts and parameters (see Parameters and Macros) in the Topology Modeler Properties tab.

The install phase does not have any environment variables.

DeployDEPLOY

Once all nodes are initialized and started, you must specify this action for services that need these files deployed into a particular service at the time of deployment.

ConfigureCONFIGURE

Modify a configuration based on a requirement – If an application like NginX requires all the IP addresses for each application tier, you can configure this service to perform the related actions.

StartSTART

A service start action only occurs when all the nodes in the deployment are up and running.

Some enterprises may have a start.sh script specifically for starting the services. If you have the start.sh file in the /usr/local/osmosix/service directory, this file executes each time the service starts.

When you reboot a service, the IP address may change. This action may need you to reconfigure all connected IP addresses. So you need to call the Configure action and the Start action to complete the lifecycle process.

StopSTOP

When shutting down the node, you can perform related cleanup actions.

RestartRESTART

When you restart the system from the UI after shutting it down, you can specify what actions need to be performed.

ReloadRELOAD

The IP address changes for connected nodes. For example, if any connect node restarts for any reason in a three-tier deployment, you can configure a reload command to internally reload the affected services.

UpgradeUPGRADE

When upgrading the deployment, you can identify the dependent factors for each service.

Clean Up

CLEANUP

When a node is being terminated, you can specify the related clean up command, script, or URL.

Container Lifecycle Hooks

Container lifecycle hooks are only available for container-based services. The following table describes the container lifecycle hooks.

UI Service ActionactionName API EnumerationDescription
Post StartCONTAINER_POST_STARTAfter the container is started – see https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/ for additional context.
Pre StopCONTAINER_PRE_STOPBefore the container is terminated. – see https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/ for additional context.

External Lifecycle Actions

External lifecycle actions are available for services based on VMs (with or without agent) and external services. They are the only lifecycle actions available for agentless VMs and external services. See External Service for details on creating creating scripts for and linking to external lifecycle actions.

  • No labels
© 2017-2019 Cisco Systems, Inc. All rights reserved