+

Deploying Apps to Private Spaces

You deploy apps to a private space using Runtime Manager.

CloudHub 2.0 supports Mule runtime engine versions 4.3x through 4.4x. Mule 3.x is not supported.

Deploy an App to a Private Space

  1. From Anypoint Platform, select Runtime Manager > Applications.

  2. Click Deploy application.

  3. On the Deploy Application page:

    1. Enter the name of the application.

      You cannot change the name of an app after you deploy it. To change the name, you must delete and redeploy the app using the new name.
    2. Select an application file:

      • To upload a Mule app JAR file from your system, select Choose file > Upload file.
        File names can contain only letters, numbers, and underscores per guidelines on unique package names.

      • To choose an example app from Anypoint Exchange:

        1. Select Choose file > Import file from Exchange.

        2. On the Get from Exchange page, enter hello in the Search assets by name:

          Get from Exchange page
        3. Click Hello World and then click Select.

    3. Select the name of the private or shared space from the Deployment Target list.

    4. Configure options for deployment:

  4. Click Deploy Application.

Specify Runtime Options

Click the Runtime tab and specify the following options:

Runtime version

Specifies the Mule runtime engine version.

Replica size

Specifies the number of vCores in the replica to run your application.

For information on replica sizes, memory, and storage, see CloudHub 2.0 Replicas. CloudHub 2.0 limits the replica size per deployment to four vCores.

Replicas

Specifies the number of replicas, or instances, of the application to deploy.

A minimum of two replicas is required for high availability.

Run in Runtime Cluster Mode

Enables Mule clustering across each replica of the application.

This option requires at least two replicas.

Deployment model
  • Rolling update:

    • Maintains availability by incrementally updating replicas.

  • Recreate:

    • Terminates replicas before redeployment.

    • Redeployment is faster and doesn’t require additional resources.

Configure Endpoints and Paths for the App

To configure endpoints for the app to enable access from the internet:

  1. Click the Ingress tab and specify the following options:

    Public endpoint
    • Domain: Select the domain, such as cloudhub.io, for the app from the drop-down list.

      If you select cloudhub.io (the default domain), you can’t select a subdomain or path.

      The administrator configures the domains and certificates (TLS context) for the private space. See Configuring Domains and Certificates (TLS Context) for a Private Space.

      After you select the domain for a private space, you can view the corresponding TLS context by clicking View TLS Context:

    • Subdomain: If the domain you selected includes a wildcard, you can configure the subdomain.

      Subdomains must start and end with an alphanumeric character and can contain only alphanumeric characters (a-z, A-Z, 0-9), hyphens (-), underscores (-), and periods (.).

      Subdomains support placeholders. The default subdomain is app-name, which resolves to the name of the app that you specified in the Application Name field when you deploy the app.

    • Path: specifies the URL path to the application endpoint.

      Paths must start and end with an alphanumeric character and can contain only alphanumeric characters, hyphens, and underscores.

      Paths support placeholders.

    • To add an endpoint, click Add Endpoint and specify options.

    • To remove an endpoint, click the X in the endpoint row.

    Path Rewrite

    If the HTTP Listener in your app listens on a different path than the path defined in Public Endpoints:

    1. Enable the Rewrite Request Paths option.

    2. Enter the target path expected by your app.

      Requests sent to your app use the path that you specify here.

    3. Click Show Example to see how the private space rewrites the path.

    TLS Options
    • Forward SSL Session

      Enables SSL forwarding during a session.

      SSL forwarding is mostly used with client authentication. See Enable Client Authentication. SSL forwarding forwards client certificate details in HTTP request headers so they are available to the application. These fields can identify an authenticated client and allow an application to determine and use the identity.

      The following headers are available:

      Header Name Value

      x-ssl-client-verify

      SUCCESS/FAIL

      x-ssl-issuer

      Client certificate issuer

      x-ssl-client-serial

      Client certificate serial number

      x-ssl-client-dn

      Contents of the client certificate DN field

      x-ssl-client-cert

      Contents of the client certificate

    • Last-Mile Security

      Specifies that TLS termination and decryption for the forwarded HTTPS connections occurs in the application.

      This option requires that the Mule application include an SSL certificate and also requires more CPU resources.

  2. Click Apply Changes to create a new configuration for your application.

Application Names

The application name you specify can contain between 3 and 42 alphanumeric characters (a-z, A-Z, 0-9) and dashes (-). They cannot contain spaces or other characters. The application name must start with a letter (a-z or A-Z). It cannot start with a number or dash and it cannot end with a dash.

To ensure that names are unique and avoid domain conflicts, CloudHub 2.0 adds a six-character unique-id to the application name that you specify in the public endpoint URL.

The application name identifies your application not only in Runtime Manager but also in the public cloudhub.io domain. For example, an application named myapp is accessible at http://myapp-unique-id.shard.usa-w2.cloudhub.io. You must have unique application names for each deployment target.

To further customize your app names, you can create a naming convention. For example, you could prepend your company name and department to all application names, such as mycompany-mydept-myapp. You can then add DNS records to hide the complex application name. For example, you might route requests to myapp.mycompany.com to mycompany-mydept-myapp-unique-id.shard.region.cloudhub.io.

Make application file names as unique as possible. An app cannot be deployed if it shares the same name as an asset in Exchange.

Placeholders

The subdomain and path support the following optional lowercase placeholders:

Placeholder Resolves to

app-name

Name of the app that you specified in the Application Name field when you deploy the app

business-group-id

Business group ID associated with the app

environment-id

Environment that you deploy the app to

Change App Behavior with Properties

You can configure property values, such as specifying the environment or setting passwords and usernames, during app deployment.

For information about configuring app properties, see:

Configure Logging for the App

Logging is enabled by default for apps deployed to CloudHub 2.0.

Disable or Enable Logging

To disable or reenable logging for the app:

  1. Click the Logging tab.

  2. Deselect or select the Enable application logs option.

  3. Click Apply Changes.

If you disable logging, the Logs heading still appears in the Runtime Manager navigation menu, but application logs are not collected.

Configure Log Levels and Categories

To configure additional log levels and categories to include in logs:

  1. Click the Logging tab.

  2. Select the log level:

    • INFO: Informative messages

    • DEBUG: Debugging messages

    • WARNING: Warning messages

    • ERROR: Error messages, such as when an exception occurs

    • FATAL: Fatal messages for when an application fails

  3. Optionally, set the log level for specific a Java package class by selecting the log level, entering the package.name, and pressing the Enter key.

  4. Click Apply Changes.

Was this article helpful? Thanks for your feedback!
View on GitHub