Custom Service Definition


CloudCenter users have the flexibility to define their own service on supported images. For instance, a user creates a Tomcat or Oracle WebLogic service on a specific hardened base OS image such as RHEL, CentOS, or Oracle Enterprise Linux. Accordingly, this user can define the scripts for different actions on each service such as starting, stopping, restarting the service and so forth.

Service Types

The service types that the following screenshot shows are available when you define a custom service.

The following table describes the service types.

Service TypeDescriptionScripts/Hooks
Virtual Machine with a Management Agent (default)

About 90% of the CloudCenter services use this type. In this case, it is nothing more than an application VM being launched with a service tied to it using a apt-get command based on the bundle script specification to install this service, and then run the required actions.

If configured, the Pre VM Start script is the first script to be executed before the VM is launched.

  1. Pre VM Start
  2. Pre VM Init
  3. Post VM Init
  4. Pre VM Stop
  5. Post VM Stop
Virtual Machine without a Management Agent

Use this service type to launch VMs in agent-less mode.

While you cannot specify Agent Lifecycle Actions (because of the lack of a Management Agent), you can still specify External Initialization actions before the actual service is started.

If there is no IP address before the actual service is started, the post/pre-init scripts inject the IP addresses and other configured information for each phase.

  1. Pre VM Start
  2. Pre VM Init
  3. Post VM Init
  4. Pre VM Stop
  5. Post VM Stop
External Service

Use this service type to configure an external service that is not launching a VM.

External service costs are not be included in the cloud costs as it is considered a component of management costs. This cost is visible in the Account Details > Usage Details page.

  1. Update
  2. Start
  3. Stop

External Initialization section in External Service

Container Service

Use this service type to configure container services.
  1. Post start
  2. Post stop
Lifecycle Hooks section in Container Service

Base OS Image Versions

The out-of-box Base OS services are not tied to a specific version. CloudCenter provides an Ubuntu base OS service that maps to the supported versions for this service. You will find similar configurations for all other OS services.

One of the supported versions is specified as the default for each base OS image and users can change to any other supported version. See Base OS services for a list of supported versions for each base OS image.

Prerequisites to Define Custom Services

Verify these prerequisites before you define a custom service:

Guidelines to Define Custom Services

Define a custom service by following these simple guidelines:

  • Define a skeleton service definition. The scripts can be in any language or format. Ensure to adhere to the Guidelines to Configure Service Scripts.

  • CloudCenter merely executes the command specified in the field for each phase of the Lifecycle Action.

  • Read and understand the Service-Tier Scripts Defined in App Models explained in the Deployment Lifecycle Scripts section.

  • Upload the logo image before creating a service.

Process to Define a Custom Service

To add a custom service, (admins) follow this procedure:

  1. Log into the CCM UI as an Admin.

  2. Access the Services tab: Admin > Services.

  3. Click Add Service to add a new service.

  4. In the Add New Service page, enter the details of the new service.

  5. Add a Service Logo for this image. Click Choose File to upload the this file to the local file system:

    • The supported image formats are PNG and JPG. 

    Logo file names for a Unison file synchronization process have a size limitation of 140 characters. If the file name is longer than this limit, then the Unison synchronization process fails recursively and other image files, including logo images, cannot be synchronized.

  6. Provide the Name for this service.

  7. Provide a Service ID. This must be a unique ID that uses only alphanumeric characters and/or underscore. If you are using scripts and created a .zip file, then use the same name as the .zip file. See Guidelines to Configure Service Scripts for additional details. For example, tomcatCentOS7 is the name used in that example when creating the service lifecycle action script.

  8. Add an optional description for this service.

  9. Select one relevant Category. 

    1. After you define the service, this service will be displayed in the Topology Modeler Services tab.

    2. The available categories are listed in the Category dropdown list. 

    3. For example, if you add a Tomcat service, select Web Server, if you are adding a SQL database server, select Database and so forth. If you find that your new service straddles two services or does not fit into any other category, add it to the Custom Service group.

  10. Select one Default Image from the selected supported images for this service (VM-based services only).

  11. Assign a Default inbound firewall rule(s) that should be used by VMs running this service, if required (VM-based services only)

    1. Select if the protocol should be TCP or UDP.

    2. Add a firewall rule for each default port as applicable. For example, Port 8080 is the default port for Tomcat service.

    3. Assign the ingress and egress port information.

  12. Assign the Service Cost to allow enterprises to optionally charge a hourly cost for the service.

    1. When modeling applications, you will not be charged when you include a charged service in your topology.

    2. You are charged at the hourly service rate only if you deploy an application that has a chargeable service.

    3. This cost adds up to the other costs incurred when deploying an application.

    4. Allows admins the flexibility to charge individual users or sub-tenants for any service that is built and added to the Marketplace or Catalog. See Cost and Fees for additional context.

  13. Provide the applicable Lifecycle Action(s) using scripts or command to execute the service on different actions. 

    1. Lifecycle actions can be one of the following:

      • Scripts: This is the most common option as scripts can be in any language or format. See Guidelines to Configure Service Scripts for additional details.

      • Commands: CloudCenter executes the command(s) specified in this field for the phase of the lifecycle

      • URLs: Downloadable by a get request

    2. Services can be present in a repository that is already modeled in CloudCenter (Repositories) or hosted on any other server (Other input). If the bundle is hosted on any other server, then provide the URL of the script.

  14. In cases where you need to run external actions, define this section – Add the External Lifecycle Actions to manage the external service lifecycle.

    Script PropertiesThe specified script is executed...
    Pre-init ScriptBefore the service is launched
    Post-init ScriptAfter the service is launched
    Pre-start ScriptBefore the service is started
    Post-start ScriptAfter the service is started
    Pre-stop ScriptBefore the service is terminated
    Post-stop ScriptAfter the service is terminated

    The External Actions Bundle file contains the scripts for external service lifecycle management.

    You must provide the following information for this zip file depending on the resource being configured:

    • If you are configuring this file at the cloud region level – this file must contain a directory called cloudregion which contains all the scripts.

    • If you are configuring this file for a service – name this file as For example,, where tomcat6 is the Service ID.

  15. Add any additional parameters required by the service scripts to the Service Parameters section.

    If you define any user-editable parameters in this section, those parameters are displayed in the General Settings section of the Properties pane in the Topology builder.

  16. Click Save to save this new service.

Now that the service is defined, it will appear on the Topology Modeler's Services pane. Once created, you can share the service across your sub-tenants. By default, the service is available to all users within the tenant. Users can access the service from the  Topology Modeler when modeling applications.

Using a Custom Service

To use the newly-defined service users can drag it into the Topology Modeler as explained in New Application Profile

The new service is visible the Topology Modeler's Services Palette in the selected Category along with the specified Base Image. For example, if you created Tomcat for CentOS 7.x as the new Web Server service you will see the following service configuration.

If you created additional parameter(s) specific to this service, you will see it as part of the General Settings in the Application Tier Properties pane. You can enter an optional war file from a repository you have configured within CloudCenter.

Firewall rules configured as part of this service are automatically set when you configure this service.

Terms & Conditions Privacy Statement Cookies Trademarks