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.
|
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:
|
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 or at any tier level if .
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.
|
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 | |
Memory | See Hardware Requirements. |
Network Interfaces | See IP Allocation Mode. |
Scratch Disk Storage (Local Storage ) | |
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
| 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:
|
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
- No labels