Application Lifecycle Management

Overview

Regardless of whether you use CloudCenter-supported Base OS images or your own Custom Image, you need to be aware of the basic concepts when managing applications and services.

Base OS images

Base OS images refer to Linux and Windows cloud images on which you install CloudCenter components. These virtual base images comprise of the underlying operating system and any operations tools required and referenced by services. See Base OS images for a list of supported images.

Each CloudCenter version ships with several installers and scripts required to create appliances for CloudCenter components.

To create CloudCenter components, you have two options:

  • Manual install - no appliances involved.
    OR
  • Appliance Install – Pre-built appliances are available for some clouds.

With either option, you need to contact CloudCenter Support to obtain the Installer Packages or Virtual Appliance packages. Using either of these packages and by following the process specified in the Install CloudCenter page, you can launch the CloudCenter virtual appliances for each component.

Once you install the required components (CCMCCO, and AMQP) and Map Images, you can begin the application (or application profile) modeling process.

Every CloudCenter deployment requires a CloudCenter Package Store (see Package Store for additional context), a hosting location for all CloudCenter-supported (out-of-box) Services and other required information. When you Install CloudCenter, all services are automatically detected by the Package Store and displayed via the Topology Modeler Properties tab.

The Services Framework

A service is one of the building blocks to model an application (or application profile) that is mapped to virtual images. CloudCenter users have the option to create an application using multiple tiers where you can stipulate each tier to use a different CloudCenter supported service (see Services) or externally-provided service (third-party services). See External Service for additional context.

When defining a new service, you can use global parameters, tier/step-specific system parameters, or user-defined parameters and add values at deployment time. See Custom Service Definition for additional context.

The Services Framework (see Service Lifecycle Actions for additional context) enables enterprises (see Service Administration) to create and add enterprise-specific, private services and make these additional services available via the Topology Modeler Services tab.

For tier-specific parameter configuration, see Service Properties.

Service Scripts

The CloudCenter platform does not have hard requirements for scripts called by a service. If you configure a script, the CloudCenter platform executes the configuration specified for each Service Lifecycle Action.

The only requirements for these scripts are:

  • The script must be contained in a folder with the same name as the service identifier.
  • CloudCenter executes the scripts relative to the extracted folder in the zip file – executed as root
  • Scripts can be called at multiple points during a deployment. See Deployment Lifecycle Scripts for additional context.

  • When modeling applications you may need to call application-specific scripts for different function (install, start, restart, and so forth). These scripts may have hard-wired values for configuration parameters that may need to be changed at deployment time. See Configuration Files for additional context.

Service Parameters

Configuration parameters represent settings that must be reconfigured when your application is deployed on the target cloud. See Using Parameters > Service Parameters

How Does an Application Profile Work?

When modeling applications or application profiles, verify the prerequisites depending on your deployment scenario. See the following pages for additional context: 
 

How Does Governance Work?

A system tag is a label that consists of a name and an optional description. You can associate system tags with application profiles and application deployments, either at the tier level or globally. You also can use system tags to add system tag matching rules to aging policies, scaling policies, security profiles, and deployment environments. See the following pages for additional context:

 

 

  • No labels