Contact Us 1-800-596-4880
  1. Homepage
  2. Runtime Manager

  3. Continuous Deployment

Continuous Deployment

logo cloudhub 2.0 active CloudHub 2.0 logo cloudhub active CloudHub logo hybrid active Hybrid logo server active Private Cloud Edition logo rtf active Runtime Fabric

You can use the Runtime Manager REST API for continuous deployment to your own on-premises servers, or to other cloud servers (outside of CloudHub). The Runtime Manager REST API enables you to programmatically access much of the functionality provided by Runtime Manager. If you want to implement continuous deployment to CloudHub, see CloudHub REST API.

You can implement the process described here as a task in the continuous deployment pipeline in the following ways:

  • As a shell (for example, Microsoft PowerShell, Bash, and so on)

  • As a script

  • As a Jenkins/Maven Plugin written in Java

For a more complete reference of all the operations, resources, methods, required properties, and expected responses that are supported through the API, see Standalone Runtime Manager API Reference or Runtime Fabric API Reference

A Mule Maven plugin that provides the same capabilities is also available. Therefore, use the process described here as an alternative if you cannot, or do not want, to use the Mule Maven Plugin.

It is advisable to create a dedicated Anypoint Platform account used exclusively for deployment and CI related activities.

Workflow for On-Premises Servers

The workflow explained below can be carried out by various means, depending on your preference, but the steps remain the same. The high-level steps are as follows:

  • The user is signed into Anypoint Platform.

  • Information about the servers, server groups, and clusters that are registered on that account is obtained.

  • An application is deployed to it.

  • The application interfaces with the APIs for access management and Runtime Manager.

The workflow must receive the following input parameters:

  • Username - The Anypoint Platform account username

  • Password - Password for the Anypoint Platform username

  • Environment - The deployment environment (for example, Dev, Test, Prod)

  • Target Name - The name of the target to which to deploy the application

  • Target Type - The type of target (Server, Cluster, ServerGroup, Runtime Fabric)

  • Artifact Name - Name of the Mule application to deploy

  • File - The binary file of the Mule application to deploy

The workflow executes the following API calls in sequence:

workflow

To use the Anypoint Platform Access Management API:

  1. Call /login on the Access Management API with a valid Anypoint Platform user name and password to obtain the access_token and token_type to use in all the subsequent calls.

    If using Jenkins, the Username and Password must be configured in the task. The task has to concatenate the token_type and access_token and save them for the duration of the entire workflow process. The fields must be concatenated as follows: token = token_type + " " + access_token, for example: "bearer 895d1a05-ba24-44f2-a9df-3675c1bde97b".
    The token in its concatenated form must be passed as a header in every subsequent API call.

  2. Call /accounts on the Access Management API to retrieve the organization id.

    The task must then extract the organization identifier from the location 'user.organisation.id' and save it for later use. This step is not mandatory, as the organization identifier can be passed as a local parameter to the task due to its static nature.

  3. Call /environments on the Access Management API, passing the organization id retrieved in the previous step and choosing the correct environment id based on the relevant environment name (for example, Dev, Test, Production, and so on).

    The organization id retrieved in Step 2 must be passed as part of the API URI. The environment id must be extracted from the path 'data[i].id', where 'data[i].name == inputEnvironment' (it can take values like 'Dev', 'Test', 'Production' or any valid environment name that is set up in your Anypoint Platform).

To use the Standalone Runtime Manager API:

  1. Call either /servers, /clusters, or /serverGroups on the Runtime Manager API, passing the server, cluster, or server group name, as well as the retrieved organization id and environment id. This call returns all of the data about this server, cluster, or server group, including the targetId.

    This step retrieves the target id, which is then used as a target for the deployment. The task needs to pick up the right server, server group, or cluster identifier based on the target name you set as an input at the beginning of the workflow. The server id must be extracted from data[i].id, where data[i].name == inputTargetName.

  2. Call /applications on the Runtime Manager API, passing the organization’s id and the environment’s id, to retrieve the application’s id and the rest of its data.

    This step retrieves the application id to determine whether the following step is a new deployment (6a) or a re-deployment (6b). The application id must be extracted from 'data[i].id' where 'data[i].artifact.name == inputArtifactName' and 'data[i].target.id == serverId' / 'clusterId' / 'serverGroupId'.

  3. Post /applications on the Runtime Manager API, passing the organization’s id, the environment’s id, 'artifactName', targetId (retrieved in Step 1 of this section), the Mule application .zip file to deploy and, optionally, the application id.

This step deploys the actual Mule application artifact for the first time to a target environment and server / cluster / server group. Use POST requests if no application identifier was retrieved in Step 2. Use PATCH if an application identifier was retrieved in Step 2, to re-deploy the actual Mule application artifact to a target environment and server / cluster / server group.

Workflow for On-Premises Runtime Fabric

The workflow explained below can be carried out by various means depending on your preference, but the steps remain the same. The high-level steps are as follows:

  • It first logs your user into the Anypoint Platform

  • Information about the Runtime Fabrics that are registered on that account is obtained

  • An application is deployed to it

  • The application interfaces with the APIs for the MuleSoft Anypoint Platform Access Management and Runtime Manager.

The workflow must receive the following input parameters:

  • Username - The Anypoint Platform account username

  • Password - Password for the Anypoint Platform username

  • Environment - The deployment environment (Dev, Test, Prod, etc.)

  • Target Settings - The type (ie: MC), name of the target to which to deploy the application, and settings

  • Exchange Reference - Reference of the Mule application to deploy in Exchange

  • Application Configuration - The application configurations for the deployment

The workflow executes the following API calls in sequence.

Using the Maven Tool

  1. Publish the artifact to the Exchange Assets Manager using Maven.

    This step is required to ensure high availability when failure occurs in the target and the Control Plane needs to re-deploy artifacts for recovery.

To use the Anypoint Platform Access Management API:

  1. Call /login on the Access Management API with a valid Anypoint Platform user name and password to obtain the access_token and token_type to use in all the subsequent calls.

    If using Jenkins, the Username and Password must be configured in the task. The task has to concatenate the token_type and access_token and save them for the duration of the entire workflow process. The fields must be concatenated as follows: token = token_type + " " + access_token for example: "bearer 895d1a05-ba24-44f2-a9df-3675c1bde97b".

The token, in its concatenated form, must be passed as a header in every subsequent API call.

  1. Call /accounts on the Access Management API to retrieve the organization id.

    The task must then extract the organization identifier from the location 'user.organisation.id' and save it for later use. This step is not mandatory, as the organization identifier can be passed as a local parameter to the task due to its static nature.

  2. Call /environments on the Access Management API, passing the organization id retrieved in the previous step and choosing the correct environment id based on the relevant environment name (for example, Dev, Test, Production).

    The organization id retrieved in Step 2 must be passed as part of the API URI. The environment id must be extracted from the path 'data[i].id', where 'data[i].name == inputEnvironment' (it can take values like 'Dev', 'Test', 'Production', or any valid environment name that is set up in your Anypoint Platform).

*Using the Application Manager API:

  1. Call deployments on the Application Manager API, passing the organization’s id and the environment’s id, to retrieve the application’s id and the rest of its data.

    This step retrieves the application id to determine whether the following step is a new deployment (6a) or a re-deployment (6b). The application id must be extracted from data[i].id, where data[i].artifact.name == inputArtifactName' and `data[i].target.targetId == `targetId`.

  2. Post /deployments on the Application Manager API, passing the organization’s id, the environment’s id, applicationName, labels, target deployment settings (including the target id retrieved in Step 1 of this section), the Exchange reference of the published Mule application 'application' to deploy, the application configuration, and optionally the application id.

This step deploys the actual Mule application artifact for the first time to a target environment and Runtime Fabric. Use POST requests if no application identifier was retrieved in step 2. Use PATCH if an application identifier was retrieved in step 2 to re-deploy.