/*Here i feel is the placement of version dropdown*/

Model a New Application Profile


Application Modeling is the process of capturing all images, scripts, and other dependencies required to fully deploy an existing, working application and build them into a model that you can configure using the CloudCenter platform.

The CloudCenter platform application models are composed of services. If the VM deployment is required for the service, then it can be mapped to a logical VM image. The logical VM images are in turn mapped to real images on a per-cloud basis (for example, AMI, VM-snapshot or template name, QCOW, and so forth depending on the cloud you use). See Map Images for additional context.


  • Application Discovery: Begin your application modeling using a top-down approach focused on the application requirements. In this phase, nothing is configured in the CloudCenter platform. 
    1. Consider all of the services that make up the application (for example, Apache, Tomcat, JBoss, MySQL, Cassandra, SQL Server, and so forth).
    2. How are those services dependent on each other?
    3. Where are the artifacts that are required for the services to be successfully deployed?
    4. Are the services better deployed in a modular fashion, on small, discrete VMs or containers? Or is it better to lump some of all of them together onto a single VM?
    5. What are the networking requirements for each service to talk to the others?
    6. Are there external services that need to be connected to and communicated with (for example, a new schema on existing SQL Server Cluster, New VIP on existing Load Balancer, and so forth).

    The outcome from this step in the design process should be a topology diagram showing all the required VMs and external services, the ports required between each service, and which services are deployed on which VMs.
    See Application Discovery for additional context.

  • Required Services: Services should be developed to be usable in as many applications as possible without needing to re-modeling the same service each time. This will ensure future efficiency. For each service in the application, consider:
    1. Is there already a CloudCenter platform-provided Service that can be used? Or can an existing service be slightly modified to support this application?
    2. How can this Service be modeled to be generic?
    3. How is that service going to be deployed on the VM? Using scripts or perhaps Chef or Docker?
    4. If this is an external service, can you write a script to connect to that service and carry out whatever work is required? Are there existing libraries available that make this easier? Is one language or another easier for this? For example Python/requests VS Bash/curl VS Python library and so similar? Did you check out the corresponding libraries, for example, the Python library?
    5. What images do you need to support for this service? Is one image sufficient? Can you make this image cross-compatible with minimum effort? For example use the [ -z /etc/redhat-release] command to verify if you're on a CentOS/RedHat type system.
    6. Which inbound and outbound ports do you need to open for this service to function?

    The outcome of this step should be a list of all services that your application requires, with a reference to the existing service that will be used if one is suitable.

  • Supported Images: The VMs deployed by the CloudCenter platform must be clones of existing Base OS Images. These are stored on each cloud as AMIs, QCOWs, VM Snapshots or VM Template Names, and so forth. These images are the foundation to build higher-level services. In an ideal case they are very simple and generic, but often also have required security tools, monitoring agents, etc on them that will be included in every VM.

    Keep in mind that services reference LOGICAL images, not real ones. The logical image references one REAL image per cloud region. This is an important part of how the CloudCenter platform achieves cloud portability. The application and associated services are not dependent on any specific piece of infrastructure, not even the cloned images.

    For each Logical Image required for your services, consider:

    1. Is there an existing Logical Image that is suitable. If not, is there one that's close enough that can be made to work, or can your service be modified to fit?

      IMPORTANT Considerations

      1. Don't make a new instance of a Logical Image type unless absolutely necessary.
      2. Ideally you will have only one Logical Image for each type of OS that you require - and be sure to use as few OS types as possible.
    2. If not, and if you need to create a new Logical Image:
      1. On what cloud regions do you need to run this image?
      2. What OS do you need to use for this image?
      3. Is there a standardized image build script that you can use?
    3. What tools do you want to build into the image, if any?
    4. Don't add application or service-specific configuration as it will be less usable for the next service.
    5. If you have a suitable Logical Image to use, does it have Real Image mappings for each region where you will want to deploy your application?

    The outcome from this step should be a list of any Logical and Real Images that need to be created, how to create them, and where to create them for each services. After you have been through this a few times, the ideal outcome is generally, an empty list!

  • Modeling Process: Transition to a bottom-up approach when you model an application profile. See the following sections for detailed information.

Modeling Process

When you begin the modeling process in the CloudCenter platform – start with configuring your images, followed by services, and finally, the application model.

Create Real Images and Map to Logical Images

If you need to create any images, create the real image and map to a logical image.

  1. If you don't already have a logical Image that you can use, create the logical Image in the CloudCenter platform. See Create Image (API) or Image Administration (concepts and UI) for additional context.

  2. Create the real Image in each cloud region.

    CliQr Supported Images


    You might save some time on this if you use one of the supported out-of-box Base OS Images for your cloud, if available and suitable to your enterprise requirements.


    1. Use your internal build process to complete this step. In some cases, you may only need to deploy the OS.
    2. Install the Management Agent bundle on it using the installer. See Custom Image Installation for additional context.

  3. Apply the real image mapping to the logical image for the appropriate cloud region. See Map Images for additional context.

  4. Test the images by creating blank services and applications – just for the purpose of launching and testing each image.

Out-of-Box Images


Virtual Appliances-based services often use packaged appliance images, without modification. In this case, you do not need to install the Management Agent bundle and directly map the images.


With your required images in place, you can start setting up services. Services have an associated lifecycle framework that calls different commands at different points in the service's lifecycle. See Service Lifecycle Actions for additional context.

  1. Start with a dummy or other service script. This can be in any language, with any content that meets your needs, but a handy starting point written in bash is provided in the following Sample Script Code: This example contains a single script, called service, that is used to handle all VM lifecycle actions, with an argument ($1) used to control which behavior is activated with each step.

    Sample Script Code

    The lifecycle actions would look like:

    1. Install:
      service install
    2. Configure:
      service configure

      and so forth.

      Important Notes

      • It doesn't have to be done this way. You can use different scripts or commands or a different language like Python. This is your choice.
      • See logging details on Line 2.
      • See the sourced files on Lines 4-8. These are important to pick up helpful environment variables and utility functions.


  2. In the CloudCenter UI, under Admin > Services, create a new service with a descriptive name and type – use a dummy script as a starting point.
  3. Create a dummy application to test this service.
  4. Continue building your service by launching a new test app deployment for this service often to test progress as you go along.
  5. Refer to above service tutorial for additional detail and best-practices.


With the individual services built and tested using dummy applications, you can now pull the pieces together into the final working application.

  1. Access the CCM UI and click Applications.
  2. Click the Model link in the top right corner. The Model a New Application Profile page displays with a list of application profiles.
  3. Select a core, pre-packaged, or custom profile from the CCM UI. For example, if you are modeling a Java web application, use the Java Web App profile.
  4. Use the CCM UI's Topology Modeler to define the application architecture and other components for each tier. 
    1. Drag and drop the required service from the Services pane to the Graphical pane in the Topology Modeler.
    2. Connect the services with connectors that correspond to the order in which each service must be configured.

      • These services ARE NOT related to network dependencies in any way.
      • All VMs are created simultaneously (barring cloud-specific constraints)
      • The lifecycle actions are executed from the bottom up according to the arrangement in the Topology Modeler.
    3. Click the service in the Graphical pane and configure the Properties for this service. See Service Properties for additional details required to configure this pane.
    4. Use debugging settings to troubleshoot issues – if required:
      1. Add a global troubleshooting parameter (cliqrIgnoreAppFailure) to your application and assign a default value of true. Be sure to come back and delete this parameter once the application, services, and images are working (see Troubleshooting Parameters for additional context).
      2. For each service tier, under Node Initialization, set sudo 'ALL' and make a note to come back and change this later.
      3. These two things will be very important during the setup and debugging phase. REMEMBER TO TAKE THEM OUT LATER.
    5. Add firewalls rules as required for each Service Tier. See Security and Firewall Rules for additional context.
    6. Add additional services as required for your deployment. The configuration may differ based on the service. See the following sample services for additional context:
  5. Enter the basic information (description, logo, name, and so forth) according to the requirements for your application. See Topology Modeler > Basic Information tab for additional context. 
    1. Enter the general settings values (HTTP/HTTPS/Both/None based on the invoked protocol).


      The Protocol field provides a None option (in addition to HTTP, HTTPS, and Both) when modeling N-tier applications. If you select None, the CloudCenter platform does not add any access link URL in the application deployment detail page.

    2. If it is a non-standard port, check the corresponding box.


      For example, the default Tomcat server is started on port 8080. By setting the protocol to this port, you can access the server directly from the Deployment Details page.

    3. Enter the required values to access applications (port number in the URL, for example, if the non-standard port is 3309 and the URL will be http://IPaddress:3309. 
    4. Specify the categories and tags for this application, if any. These fields are used as filters to search for this application.
    5. Provide the Access Link (path) for the application's launch page (landing page).
    6. Add metadata as relevant for your cloud. This is a useful way to flag the VMs.

       AWS Example

      AWS displays metadata as tags on the VMs. For example, if you use

      Name / %USER_NAME%-%JOB_NAME%

      When you log into the AWS console, you can see a list of app deployments and the user who launched the VM each deployment.

  6. Define overriding parameters, if any, in the Topology Modeler's Global Parameters tab (for example, administrator, username, password, and so forth). See the Global Parameters section for additional context.
  7. Once you enter all the definitions, you have multiple choices:
    1. Click Save as App to save it to the  Application Tasks page. If you save the modified profile as an Application, the definition is saved as a metadata file that can be exported in JSON format.
    2. Click Save as Template to save it in the Model a New Application page.
  8. Test your application or application profile in each cloud as applicable to your environment.


Export Application Scripts

If you save the modified profile as an Application, the definition is saved as a metadata file that can be exported in JSON format. This section provides some sample application profile formats.

Sample JSON Format – N-Tier

This section provides a N-tier Jenkins application profile JSON Data Transfer Object (DTO) from the UI.

 N-tier Jenkins application in JSON

Sample JSON Format – Single Tier

This section provides the single-tier application profile JSON DTO from the UI.

 Single-tier application in JSON

Sample JSON Format – Batch Execute

This section provides the batch execute application profile JSON DTO from the UI.

 Batch Execute application in JSON