Application Tier Properties

Overview

The Topology tab contains three main sections (or panes in the CCM UI):

Topology Modeler Graphical Workflow: The graphical workflow for each application. When you click on a specific tier in the graphical workflow for each application, you see the configurable parameters and fields for that tier.
Topology Modeler Services: Type and group of the defined or selected service. Service properties differ based on the selected service.

Depending on the service that you select in this section, the corresponding parameters and settings may differ for each service in the Properties section.
Topology Modeler Properties: Application properties defined using service parameters to further qualify application actions. This section explains the Properties that you can configure for an application tier.

These properties include a list of property groups that are used in one or more Out-of-box (OOB) services offered by the CloudCenter platform.
Each property group explained below will differ based on the service that you model or deploy.
This section provides a list of all the parameters in each property group. If the properties differ, they are explained in the respective OOB service listing.

Terminology

Term	Definition
Service	A reusable component that operates on the supported Operating Systems. You can define a new service to capture framework dependencies (called when you onboard or migrate one or more applications).
Service library	A collection of supported Out-of-Box (OOB) Services and custom images that are included in the CloudCenter platform and supports each application stack. An OOB service is sometimes referred to as a system service or a supported service.
Custom service	A user-defined service that resides in the service library.
External service	Any service that resides in another location. See External Service for additional context.
Application stack	A composite topology that includes a variety of formats of services, images, and containers.
Topology Modeler	A CCM UI tool used to model an application profile using various profile templates and out of box services, images, and containers. See Topology Modeler for additional context.
Service Lifecycle Actions	The actions to per-determine granular steps of the service deployment process for each application. See Service Lifecycle Actions for additional context.

General Settings

This section is unique based on how the service was defined.

The following table lists the configurable properties to ensure that the application is functioning.

Properties	Description
Name	A descriptive name for this service.
Base Image	The Operating Systems in which you are installing this service.
Minimum number of nodes	The minimum number of nodes (VMs) in this cluster. If the number of active VMs (nodes) is lower than the number specified in this field, then the application may not function as designed.
Maximum number of nodes	The maximum number of nodes in this cluster. Once the number specified in this field is reached, then the application cannot be scaled.
Number of Volumes	Number of persistent data storage volumes for Web Server. See Multiple Volumes for additional context.
Default Volume Size	Persistent data storage for Web Server. Persistent Storage is defined by default for database tiers, but can be assigned manually to any tier See Multiple Volumes for additional context.
Allowed Scaling Polices	A list of available policies for this application with each policy having an info icon that displays additional details on time duration, CPU utilization, and other details. See Policies for additional details on each type of policy. If you do not select an allowed scaling policy for a tier, the scaling policy field for that tier is hidden in the deploy form and no scaling policies can be selected by users at deploy time. If only one allowed scaling policy is selected, the corresponding visibility toggle is enabled and set to on by default. If one policy is selected and the visible toggle is turned off, the scaling policy cannot be disabled at deploy time, but is still applied to the deployment behind the scenes. If at least one policy is selected, a mandatory toggle is displayed to the right of the visibility toggle and a deploy time preview link appears under the allowed scaling policies field.
	Visible: Identifies if the selected policy should be visible (ON) to users in your tenant and makes it visible in the deploy flow.
	Mandatory: This setting is only available if you switch on visibility and allows you to determine if this application should require this policy (ON) or it is an optional setting (OFF)
	Deploy Time Preview: Identifies the required time-based option for the selected policies. Refer to the info icon for the required policy in the previous step to select the corresponding option. Click the Deploy Time Preview link for a popup window to display the tier scaling policy dropdown field's appearance for that tier in the per-tier section on Page 1 of the Deploy form.
Associate Tags	A label that consists of a name and an optional description for metadata association and for tracking purposes. See System Tags for additional details.
App Config files	This field is specific to the web server. Application config files that contain system Parameters and Macros that may need to be modified at deployment time. The config file uses a relative path from the web app root folder, for example, webinfo.conf. If you are configuring multiple files, separate each file in the list using a semicolon. See Configuration Files and Parameter Substitution for additional context.
Deploy Folder	This field is specific to the web server. When you deploy an web server application, use this field to specify the /service/var/www/html root path where the folder must be created. For example, if your folder is called Doc, then this folder is created as /apache/var/www/html/Doc. The app binaries are unzipped in this folder before deployment.
Associate Tags	You can associate system tags with application profiles and application deployments, either at the tier level or globally. See System Tags for additional context.

External Initialization

Defines the scripts to be run before (pre) and after (post) the start of the Service or pre/post stopping of the service when the application is rebooted, suspended, or terminated.

External Initialization scripts are run at the same time as their equivalent service initialization scripts, but are run from an isolated container on Docker (see Virtual Appliance Overview > Dedicated Docker Registry).

See External Service for additional details on this section.

You must configure the information explained in this section:

If your deployment uses external services, to ensure that the application is functioning.
To ensure that the node is functioning.

The following table lists the configurable properties that define each script execution.

Properties	Description
VM Pre-Prevision Script	Script executed before the application VM is provisioned.
VM Pre-Initialization Script	Script executed before the application VM service is initialized.
VM Post-Start Script	Script executed after the application VM service is started.
VM Pre-Terminate Script	Script executed before the application VM is terminated.
VM Post-Terminate Script	Script executed after the application VM is terminated.

Node Initialization & Clean Up

You must configure the information explained in this section to ensure that the application is functioning.

See Deployment Lifecycle Scripts for additional details on this section.

See Service Administration for additional details on configuring the service location.

Each node initialization and clean up script is run once for each VM function.

The following table lists the configurable properties for node initialization.

Properties	Description
Initialization script	Downloaded and executed at deployment time. See Deployment Lifecycle Scripts > Lifecycle Action Script Definition
Cleanup script	Downloaded and executed at the time of deployment termination. See Deployment Lifecycle Script > Lifecycle Action Script Definition
Resume Script	Downloaded and executed when the VM is suspended and restarted. See Deployment Lifecycle Scripts > Lifecycle Action Script Definition
Deploy Packages	External packages required for each VM are bundled and referenced as an application content package in the application profile. For example, php5 sendmail. See the following pages for additional details: Deployment Lifecycle Scripts > Application Content Package Create Package Store on Premises Service Lifecycle Actions
Sudo command list	Specify a list of semicolon separated commands to allow additional SUDO access to certain scripts if using the Linux OS. For example, SUDO ALL (to allow the user to run at the root level).

Service Initialization

This section defines the scripts to be run before (pre) and after (post) the start of the Service or pre/post stopping of the service when the application is rebooted, suspended, or terminated.

Once the node initialization is complete, CloudCenter downloads the Bundle Store to the VM and unzips the file in the specified location. See Deployment Lifecycle Scripts for additional details.

You must configure the information explained in this section to ensure that the application is functioning.

Service initialization actions at the application tier level are not called automatically. You must call them explicitly from within the service scripts.

This behavior is different from other initialization actions (like external initialization and node initialization actions) that are called automatically.

The following table lists the configurable properties after node initialization is complete.

Properties	Description
Pre-Start Script	Script executed before the service is started.
Post-Start Script	Script executed after the service is started.
Pre-Stop Script	Script executed before the service is stopped.
Post-Stop Script	Script executed after the service is stopped.

Firewall Rules

The firewall rules that are specified as part of the application profile are used to configure the cloud provider firewall. These firewall rules can be applied to Cloud based Security Groups or features like ACI contracts.

Although it is not possible to explicitly specify security policies for each tier in the application profile, any allowed security policy specified in the deployment environment form can be selectively applied to each tier at deploy time. If you want to define per tier security policies that are unique to each tier, consider defining firewall rules for each tier in the application profile instead.

If microsegmentation is enabled:

If you disable microsegmentation, after enabling it and configuring any change, all firewall rules revert to the initial state – any changes associated with the microsegmentation configuration are lost.

The default firewall rule for a service are automatically displayed in this section if it is the top tier for the app.
If service-level microsegmentation is enabled, you can restrict any firewall rule to any tier by specifying the tier name or IP for the source.
See Security and Firewall Rules for additional context.

As soon as you connect the service in the Topology Modeler, the IP column in the Firewall Rules section automatically updates to display the Apache service tier name. You can choose to keep the preconfigured firewall definition or add additional Firewall rules as required.

The following table lists the configurable properties for service-level firewall rules.

Properties	Description
IP Protocol	Defines the protocol to be used by VMs running this service. TCP: Transmission Control Protocol UDP: User Datagram Protocol
From Port	The initial port number of the port range to use for the inbound firewall rule (or security rule).
To Port	The final port number of the port range to use for the inbound firewall rule (or security rule).
IP/CIDR/TIER	The default CIDR for the application tier defaults to 0.0.0.0/0.

Deployment Parameters

Once the Node initialization is complete, the application is capable of functioning as configured. Once the node is up, the utility files can be sourced in the script. See Deployment Parameters for additional context.

Custom parameters are part of the userenv file ( /usr/local/osmosix/etc/userenv). This file contains the dynamically-generated information that is used for advanced scripting and orchestration purposes. See Deployment Lifecycle Scripts > Utility Files and Configuration Files for additional context.

To add additional parameters that are specific to each step or tier, provide the parameter information listed in the following table.

Properties	Description
Parameter Name	Identifies the name for this custom parameter.
Display Name	Identifies the display details for this custom parameter.
Help Text	Identifies the help text required when using this custom parameter.
Type	See Using Parameters > Parameter Type.
Default Value	Identifies a default value, if provided, for this custom parameter.
User Option Checks	See Using Parameters > Granular Control for User-Defined Parameters.

Hardware Specification

Identifies the hardware specification for each application tier. The following table lists the properties used to filter the instance type based on your minimum hardware provisioned for your deployment.

Properties	Description
CPUs Needed	See Hardware Requirements.
Memory	See Hardware Requirements.
Network Interfaces	See IP Allocation Mode.
Scratch Disk Storage (Local Storage )	See Manage Instance Types.
Provision Hardware Server	See Provision Bare Metal Hardware Servers.

Environment Variables

Environment variables help servers find the directory to install files, the location to store temporary files, and the settings to find the user profile(s).

This section is similar to Custom Parameters for N-Tier applications. The only difference is that you can define the type for Custom Parameters (type is not configurable for Environment Variables).

The following table lists the configurable properties for environment variables.

Properties

Description

Name

Identifies the name for this environment variable.

Value

Identifies a value for this environment variable.

User Options

Visible
Editable
Optional

See the following pages for additional context:

Migration

You can set migration parameters that your application may need here. The migration for the Database tier will be done automatically, if the scripts are not specified. See Deployment Lifecycle Scripts for additional context.

The following table lists the configurable properties for migration scripts.

Properties	Description
Pre Migrate Script	Script is executed before the backup.
Backup Script	Backup Script writes the backup files to a Backup Folder.
Backup Location	Location (path) where the application files are backed up/restored. This is a required field for any application requiring data backup.
Restore Script	Read from the backup files in the Backup folder. The Restore Script runs after the service is started and the Post-Start Script has run, except in case of the Database tier, where the Post-Start Script runs after the Restore Script.
Post Migrate Script	Script executed after the restore is run.

Upgrade

You can upgrade an existing deployment by specifying the upgrade scripts for each tier. Specify the upgrade parameters in the sequence to be executed. See Deployment Lifecycle Scripts for additional context.

The following table lists the configurable properties for deployment upgrades.

Properties

Description

Upgrade Type

Define upgrade scripts for the node:

Auto: Upgrade the tier with latest package and any backup/restore content (if specified).
Advance: Allow additional scripts and steps during the upgrade process. You can specify scripts for each step separately.
None: Exclude the Node/Tier from upgrading.

Pre Upgrade Script

Script is executed before the upgrade.

Post Upgrade Script

Script is executed after the upgrade.

Other References

The following table lists additional references related to application tier configuration.

Task	Reference Link
Model a new application profile	See New Application Profile.
Model an application	See New Application.
Understand the Topology Modeler	See Topology Modeler.
Understand application modeling	See Application Lifecycle Management.
Understand script lifecycle flow	See Deployment Lifecycle Scripts.
List of supported services	See Services.
Add a New Service	See Define a Custom Service.
Manage Services and Scripts	See Service Administration.
Parameters	See Using Parameters.

Back to: Service Properties