Nav

Deployment Strategies

Runtime Manager allows you to deploy your Mule applications to Mule runtime instances in several ways, depending on your Mule runtime server topology. These are the different deployment strategies available to date.

Indicator Icon Runtime Manager Location App Deployment Target

logo cloud active

Runtime Manager Cloud console

CloudHub

logo hybrid active

Runtime Manager Cloud console

Your Own Mule Servers

logo server active

Anypoint Platform Private Cloud Edition

Your Own Mule Servers

logo pcf active

Anypoint Platform Private Cloud Edition

A Pivotal Cloud Foundry repository that manages an instance of Mule runtime.

See deployment instructions

If you are interested in requesting the Anypoint Platform Private Cloud Edition, please contact your sales representative.

Note that every page in the Runtime Manager documentation is tagged with the following set of icons. They are a quick indicator of what deployment strategies are relevant to the content explained on the page.

logo cloud active logo hybrid active logo server active logo pcf active

These are otherwise grayed out.

diagram1

In Anypoint Studio, hitting the Play icon (or right-clicking project on the Package Explorer and selecting Run As > Mule Application), deploys your application to an embedded test server that is built into Studio. This server is not meant for production deployment and uptime restrictions apply. Ultimately you will want to deploy your application into one of the deployment scenarios described below. All of these are supported by the Runtime Manager.

Deployment Scenarios

This section gives you an overview of each basic architecture that the Runtime Manager enables you to set up for hosting and managing your Mule applications.

Runtime Manager to CloudHub Deployment logo cloud active

ch

CloudHub is a complete Platform as a Service that covers all of your server needs out of the box, including Object Store infrastructure, Monitoring, Troubleshooting, Scheduling, etc.

Through the Cloud console of the Runtime Manager, you can easily deploy to CloudHub without needing any prior configuration of other elements.

You can pick what portion of the resources that your contract allows you to use to assign to your application. If your application runs on multiple CloudHub workers, a load balancer automatically takes care of dividing incoming traffic evenly. See Load Balancing and Domain Names for more on this.

See the sections below to find out what specific operating features apply to this modality and how to configure them. Also, see Developing Applications for CloudHub for the specific things that need to be set up on applications that are deployed in this way.

Cloud Console to Your Own Servers (Hybrid)

logo hybrid active

hybrid

The hybrid scenario of hosting your apps on your own servers while managing them via the cloud allows for greater flexibility and tighter security (in case you deploy to your own secured on-premises environment). On the other hand, it requires that you sort out several considerations by your own means, such as Object Store infrastructure, Shared Resource Support and Logging.

To make a server visible to Runtime Manager, you must first register it by running an instruction on the server’s command line, see Add a Server. You then have the flexibility to group servers into Server Groups or Clusters to make them a High Availability deployment target. You can then choose to deploy your applications to either a server, server group or cluster.

See the sections below to find out what specific operating features apply to this modality and how to configure them.

On-Premises Console On-Premises Deployment logo server active

onprem

For customers with strict regulatory or compliance requirements that limit the use of cloud solutions, MuleSoft offers Anypoint Platform Private Cloud Edition - a containerized distribution of the management and engagement capabilities of Anypoint Platform deployable on-premises or in a customer’s private cloud environment.

This alternative allows you to have have both your platform and deployments on-premises. Keep in mind that implementing it requires that you do some extra leg work, and is currently lacking some operating features. As with the hybrid scenario, you need to take extra steps to work out Object Store infrastructure, Shared Resource Support and Logging.

This packaging of the anypoint platform is currently lacking some Dashboards, Insights, as well as some of the alerts that are available in other deployment modalities.

To make a server visible to Runtime Manager, you must first register it by running an instruction on the server’s command line, see Add a Server. You then have the flexibility to group servers into Server Groups or Clusters to make them a High Availability deployment target. You can then choose to deploy your applications to either a server, server group or cluster.

See the sections below to find out what specific operating features apply to this modality and how to configure them.

On-Premises Console to Pivotal Cloud Foundry Deployment

logo pcf active

pcf

If your IT infrastructure is built on Pivotal Cloud Foundry (PCF) to virtualize local resources, you might be interested in leveraging this platform to deploy Mule applications to dynamically allocated resources. Runtime Manager is integrated with PCF, by simply picking PCF as a deployment target on the UI, you can deploy to your PCF instance.

This deployment strategy is only available through the Anypoint Platform Private Cloud Edition, so the same limitations apply as described in the prior scenario. It requires that you do some extra leg work, and is currently lacking some operating features. You need to take extra steps to work out Object Store infrastructure, Shared Resource Support and Logging.

This packaging of the Anypoint Platform is currently lacking Dashboards, Insights, as well as alerts. Future releases will bridge those gaps further.

Each time you deploy an application, the PCF instances a new Mule server out of the dynamic resources that are available – following the specifications indicated on the used buildPack – and then deploys your application there. You can scale a deployment by choosing a replication factor, that defines how many instances of a predefined scale are to be launched.

See the sections below to find out what specific operating features apply to this modality and how to configure them.

Management Features

Building applications for CloudHub or an on-premises server is easy. However, there are some differences as you move from an on-premises deployment to CloudHub. CloudHub provides more out-of-the-box functionality, such as load balancing, but has some limitations which you may need to adapt your application to.

See Developing Applications for CloudHub, which illustrates the differences between apps destined for cloud and on-premises deployments, and shows some best practices for developing applications for CloudHub.

Although the basics of building a Mule application are the same, the different deployment modalities offer distinct management features. One major reason is that each modality uses a different Agent when communicating with servers:

  • When deploying to CloudHub, the older "MMC Mule Agent" is used. This agent was originally created for the legacy Mule Management Console (MMC).

  • When deploying to a server that you manage, whether through the cloud console or the on-premises Runtime Manager console, the Runtime Manager Agent is used.

diagram1

Although the long term plan is to converge the features of these deployment mechanisms so that they all offer the whole set of capabilities, currently they differ as follows:

Deploying to a CloudHub worker Deploying to a server you manage

Logs are handled by CloudHub

You can configure the Runtime Manager to send data to External Analytics Software such as Splunk or ELK

CloudHub has its own Insight Engine

You can also configure the Runtime Manager to send data to External Analytics Software such as Splunk or ELK

You can manage Schedules through the Runtime Manager UI

You must use the Poll Scheduler element in your flows to schedule tasks

CloudHub has its own preconfigured default Object Store you can reference. To use it, simply add an Object Store connector and set its 'config_ref' to point to the default CloudHub Object Store.

To use Object Stores you must configure your own database to store data

Load Balancing and Domain Names

For requests from external clients and applications, you can use the default load balancer configuration that CloudHub includes out of the box. In that case, CloudHub provides two hosts for you: 

  • myapplication.cloudhub.io - Routes information to the CloudHub load balancer

  • mule-worker-myapplication.cloudhub.io - Routes information directly to your application, bypassing the load balancer. If you have multiple workers, then this DNS round-robins between them.

You can also hide these public URLs through your DNS name servers. For example you could create A records to route requests to myapplication.mycompany.com to myapplication.cloudhub.io.

Alternatively, CloudHub includes an optional dedicated Load Balancer that you can add to a Virtual Private Cloud (VPC) for handling the DNS and load balancing of your applications within the VPC, and to define custom firewall rules within your VPC, such as to expose other inbound TCP ports besides ports 80/443 and 8081/8082. Through this, you can apply vanity domains and host your applications under any URL you choose.

vpc

To utilize the load balancer, your application must use specific ports that CloudHub allocates for your HTTP and HTTPS endpoints. See Developing Applications for CloudHub for more details.

On deployments that are done to clusters and server groups on-premises, load balancing is handled automatically at the time of deployment.

In the case of PCF deployments done to multiple instances, load balancing is also taken care of automatically.

How to Name Applications on CloudHub

Even if you use a dedicated load balancer, the actual deployed application is always deployed with a public application name myapplication.cloudhub.io. The application name must be globally unique among every application, across every CloudHub customer. For this reason, it is a good idea to agree on a naming convention for your applications that is protected by your company domain. For example you might always prefix your applications with mycompany and perhaps with a department name, so for example you might use a naming convention of mycompany-mydept-myapplication.

You can then add your own DNS records to hide this complex application name, so for example you can route requests to myapplication.mycompany.com to mycompany-mydept-myapplication.cloudhub.io.

High Availability

CloudHub provides high availability through CloudHub Fabric. CloudHub Fabric provides a combination of load balancing, persistent message queues, and horizontal scaleout. In addition, the platform also actively monitors services and workers for problems. For example, in the case of hardware failure, CloudHub auto-migrates the application to a different worker using CloudHub zero downtime updates, minimizing down time.

Deploying on-premises (both via the cloud and the on-premises console) offers high availability capabilities through creating Clusters and Server Groups. Clustered Mule instances have distributed shared memory. This shared memory is used to provide persistent VM queues, transactions, and cluster-wide data storage.

You can set a higher replication factor, which deploys your app to multiple instances. Through PCF settings you can configure how much each of these instances is worth in terms of scale.

Clustering for High Performance is not supported on PCF.

Managing Properties

For Applications On CloudHub

The easiest way to load properties on applications deployed to CloudHub is to use the Properties tab on the Runtime Manager. There you specify Java system environment variables which will function in the same way as adding environment variables when you deploy to an on-premises server.

Just like with on-premises Mule runtime deployments, you could instead add a mule-app.properties file inside the deployable application archive file. CloudHub then loads these properties into the application when the application starts.

On CloudHub, it’s not recommended to configure an external location to add property placeholders.

When your application is deployed, entries in the CloudHub Properties tab override any other property with the same name that you may have defined in the bundled files within the application.

It is possible to change the behavior of the application to not allow CloudHub properties to override properties bundled with the deployable archive. You do this by changing options in the Property Placeholder element in the Mule application. See Spring documentation on Property Placeholder options for more information on non-default property placeholder options.

Note that you can flag application properties as secure so that their values are not visible to users at runtime or passed between the server and the console. See Secure Application Properties for more information.

See Developing Applications for CloudHub for best practices on how to handle properties on CloudHub.

For Applications On Premises

With an on-premises Mule runtime you can add properties in several ways. The most common one is to add a mule-app.properties file in the application .zip bundle listing these. The Runtime then loads these properties into the application when the application starts.

Otherwise, there are several ways you can override the property values in this file bundled inside the application.

  1. You can configure an external location to add property placeholders or secure property placeholder files to override properties.

  2. You can set Java system environment variables at deployment time to override properties.

To use the second option, with an on-premises server you could deploy your application through the following command:

mule -M-Dsecret.key=toSecretPassword -M-Denv=prod -M-Ddb.password=secretPassword -app myApp.zip

In this case all the values typed into the command would only be stored in memory and must be provided every time, they are never stored in any file.

For Applications on PCF

In PCF, you can also set properties that are specific to binded services, such as credentials that are directed to a binded MySQL data base. These properties are set on the Service Bindings Tab

Monitoring

Alerts and Notifications

Most scenarios include the possibility of setting up Alerts for when certain events occur. The available alerts differ depending on the deployment modality, see Alerts for a full reference.

Besides the established list of events that can trigger an alert, CloudHub allows you to set up Custom Application Alerts and Notifications. These can be triggered by any event that you wish, by adding a CloudHub connector to your app’s flows.

CloudHub also features a set of standard Notifications that pop up to inform of certain events regarding your applications.

When deploying to your own servers (both via the cloud and the on-premises console) you can also create alerts that are triggered by events related to the servers they run on, such as reaching a certain CPU usage threshold or adding a new node to a cluster.

Alerts are not supported on PCF deployments.

Dashboards

The Cloud console of the Runtime Manager displays dashboards with performance metrics for all applications deployed, both to CloudHub workers and to servers on-premises. It also shows dashboards for the on-premise servers your applications run on.

The Anypoint Platform Private Cloud Edition doesn’t currently support the dashboard feature.

Troubleshooting

Insights

Transactions carried out on applications deployed to CloudHub can be scrutinized through the Insight Engine.

Anypoint Platform Private Cloud Edition doesn’t currently support the insights feature.

Logging

CloudHub provides a logging service for allowing logs to be searched, downloaded, or log levels to be customized. See Developing Applications for CloudHub for more details.

On-premises applications can send data to external tools to manage your logs, see Sending data from Runtime Manager to External Analytics Software. You can use custom log4j properties files.

For applications deployed to PCF, logs aren’t supported but you can view logs directly on Pivotal’s console.

Object Store

CloudHub provides an implementation of the user object store. This makes its usage a lot simpler, as you can simply reference the already configured CloudHub object store. It places limits on the usage of this to avoid abuse. These are detailed on the Object Store page.

Deployments on-premises require that you set up your own objet store, see Mule object stores.

For deployments to PCF, it’s recommended that you store your data outside the Mule runtime instance where your application runs, since its data will be lost whenever the application is stopped. Instead, you can for example can create a service binding to a database that runs elsewhere.

Disk Persistence

Using the CloudHub object store doesn’t guarantee that writing to disk survives hardware failures. Instead, you might prefer to use an external storage mechanism to store information. For small amounts of data, you can use the Object Store. For applications that have large data storage requirements, we recommend use of a cloud service such as Amazon S3. For temporary storage, the File connector is still available and can be used with the /tmp directory.

Shared Resource Support

Since each application deployed to CloudHub runs on a separate virtual server, there is no need to use domains to enable sharing ports or other resources between apps.

When deploying on-premises, it’s possible to create 'Domain' mule projects that don’t hold any flows, but do hold a set of global configuration elements to share among other apps deployed to the same server. This can be of help to avoid having to configure the same settings and credentials for each application, but it’s specially useful when you want multiple applications to listen on a same HTTP host and port, or on other exclusive resources. Read more.

Currently, you can’t deploy domains through the Runtime Manager console, even to local servers where they could be needed in some scenarios. In those cases, you can still deploy your domains manually directly on your local server through the command line.

Scheduling

CloudHub lets you define Schedules through the Runtime Manager UI that runs your flows automatically.

For apps that you deploy to servers on-premises, through any modality, this is not an option. You can achieve the same by including the Poll Scheduler element in the flows of your application.

JDK Versions

The version of JDK that CloudHub implements for all apps built with Mule runtime 3.5.1 or greater is JDK 1.7. Mule runtime 3.7.0 also supports JDK 1.8. Apps built with runtime 3.5.0 or older are deployed with JDK 1.6.

For apps deployed on-premises, see the runtime release notes of the specific runtimes you’re using to know the minimum JDK supported version.

Automatic Security Updates

Certain updates are automatically applied to applications deployed to CloudHub. Once deployed and running, if any security patches, OS updates, or critical bug fixes are released for the selected runtime version, then you will be prompted about this change. You will be able to control exactly when each update is applied. If you take no action, updates will be applied automatically for you after 30 days to ensure your applications run with the latest security patches.

For applications that are deployed elsewhere, you must carry out these Runtime updates manually.

Other Components

There are some components for which CloudHub has limited support for currently:

  • Distributed locks: currently, CloudHub cannot coordinate invocations of FTP and File endpoints across multiple workers.

  • Idempotent routers works with in memory stores and according to the limitations of the CloudHub Object Store if you configure it to use it. If those options do not fit your needs, you can use another Object Store.

Deployment Strategy Flexibility

If you want to deploy a same Mule application via various different deployment strategies – such as to an on-premises server and CloudHub – you should abstract some parameters of the application to application properties that you can set with different values in each use case, without needing to alter the actual application.

Create an application properties file named mule-app.properties in the src/main/app folder of your project. When using the properties tab on CloudHub or PCF, these properties are overriden. See Managing Properties to see how these are loaded with values in each case.

Using Different Environments

The Anypoint Platform enables you to handle separate Environments, such as production, QA, Dev, or any other custom one you may want to create. You can set some of these to be sandbox environments, which allows you the freedom to test and experiment away from the public eye.

Regarless of the deployment strategy used, deployments are always done onto a specific environment. Each manages a different set of deployments, and accessing each requires a different set of permissions, allowing you to divide roles clearly between the different teams of your organization.

Once an application has been tested in a sandbox environment and is ready for production, it can be directly promoted to a production environment, without needing to upload the application again. See deploying to your own servers or deploying to cloudhub to see how to do this.

Legacy Alternatives

You can also deploy and manage your applications to Mule runtimes through other methods that exist from before there was an Anypoint Platform. These methods are still currently supported, but no new features are being added to them: