Contact Us 1-800-596-4880
  1. Homepage
  2. Mule Runtime (3.7)
  3. Deploying

  4. Deploying to Multiple Environments

Deploying to Multiple Environments

Mule Runtime Engine versions 3.5, 3.6, and 3.7 reached End of Life on or before January 25, 2020. For more information, contact your Customer Success Manager to determine how you can migrate to the latest Mule version.

This page describes a feature that is currently available using Mule Studio (December 2013). Download and launch the latest version of Mule Studio to take advantage of this feature.

Throughout the different phases in the development lifecycle, like QA, pre-production or production, your application may need to be configured differently as server names, credentials and other similar parameters will vary.

As a developer facing this kind of variability, your goal is to produce a single Mule application for all your environments and to externalize all the environment-specific configuration parameters. This is the key to reproducible deployments.

You can configure your Mule application to facilitate deployment to one of many different environments, both on-premises and in the cloud. To do so, you must complete the following macro steps:

  1. In your application, create a properties file for each environment.

  2. Configure a property placeholder in your application to look for the deployment environment upon launch.

  3. Configure an environment variable to point to a specific environment during application deployment.

Consider externalizing other aspects of your configuration, like time-out values, polling frequencies, etc…​ even if they don’t vary between environments. This will facilitate tuning and experimenting as the whole Mule application would become configurable through a single properties file.

Should you need to encrypt passwords in your properties file, consider using the Mule Credentials Vault. Refer to the documentation for Anypoint Enterprise Security for more information on securing applications in Mule.

Assumptions

This document assumes that you are familiar with the exercise of building and deploying Mule applications in Mule Studio.

Basic Anatomy

If you’re deploying multiple applications through a Shared Resources structure, then you shouldn’t set anything in the properties files, as there might potentially be conflicts between the various apps that share a domain. Instead, you can set environment variables over the scope of the deployed app, its domain and other apps under that domain.

As explained in the Shared Resources page, in Studio you can create these variables through the Environment tab of the Run Configurations menu, reachable via the dropdown menu next to the Play button.

Consider the following Mule configuration fragment that defines an HTTP connector with variable configuration:

<http:listener-config name="HttpListenerConfiguration"
                    doc:name="HTTP Listener Configuration"
                    host="${mule.env.host}"
                    port="${mule.env.port}"
                    basePath="${mule.env.path}" />

This example uses Spring’s property placeholder resolution mechanism. The variable bits are clearly visible: the base path, host, and port can vary for each environment where this connector gets deployed in. When deploying your application, mule.env can be dynamically replaced by the particular environment you’re deploying to, such as qa or prod.

To provide values for these variables, we use a standard Java properties file:

qa.basePath=test/products
qa.host=localhost
qa.port=8082

You could then add also a second properties file with other values assigned to the same variables and entirely avoid having to touch your application’s code to change these values:

prod.basePath=products
prod.host=www.acme.com
prod.port=8081

Use a consistent naming strategy for your properties and make them unique across applications: this will greatly facilitate re-use across teams.

A good strategy is to use the application name or ID in the default and override properties file names.

Configuring an Application to Deploy in Multiple Environments

Follow the steps below to configure your application with variable properties.

Studio Visual Editor

  1. Define a list of environments you wish to support in your application. For example, one common use case involves configuring the application to support both Production and a QA environments.

  2. Right-click the src/main/resources folder, then select New > File to create a properties file for each environment you wish to support. For example:

    • qa.properties

    • production.properties

      properties_files

  3. Double-click each of these new files to open them in new tabs in Studio. By editing hem, you can configure the properties of the environment that correspond to the filename. For example, in production.properties, you may wish to add the properties as per the image below. Keep in mind that you can use these properties anywhere in your application.

    properties

    Learn how to encrypt a properties file using the Mule Credentials Vault.

  4. Close the properties files.

  5. Click in the Global Elements tab of your Studio project, below the canvas.

  6. Create a new global element. When selecting the element type, pick Property Placeholder under Component Configurations.

  7. Set the value of the Location field to ${mule.env}.properties

    Learn more about configuring variable properties.

  8. To configure Studio to use a specific environment when deploying on-premise , debugging or using DataSense to retrieve metadata from a SaaS provider, double-click to open your application’s mule-project.xml file, located in the root directory of your project.

    If you deploy your application to the cloud, right click on your application in the package explorer and select Deploy to Anypoint Platform → Cloud. Studio allows you to specify your environment variables prior to deployment, effectively enabling you to choose your deployment environment at runtime.

  9. Add an environment variable named mule.env with a value that matches the environment to which you wish to deploy by default (in the image below, the value is qa).

    runtime_env

  10. Close the mule-project.xml file, then save your application. When you debug your application or deploy it on-premise, Studio deploys to the environment you specified in the mule-project.xml file.

  11. To change the default deployment environment at any time, change the value of the environment variable key. For example, to deploy to a test environment – assuming you have a test.properties file in your application– change the value to test.

XML Editor

  1. Define a list of environments you wish to support in your application. For example, one common use case involves configuring the application to support both Production and a QA environments.

  2. Right-click the src/main/resources folder, then select New > File to create a properties file for each environment you wish to support. For example:

    • qa.properties

    • production.properties

      properties_files

  3. Double-click each of these new files to open them in new tabs in Studio. By editing hem, you can configure the properties of the environment that correspond to the filename. For example, in production.properties, you may wish to add the properties as per the image below. Keep in mind that you can use these properties anywhere in your application.

    properties

    Learn how to encrypt a properties file using the Mule Credentials Vault.

  4. Close the properties files.

  5. At the top of your XML config, above all other flows, add a <context: property-placeholder/> element with a resources attribute configured as per below.

    <context:property-placeholder resources="$mule.env.properties"/>

    Learn more about configuring variable properties.

  6. To configure Studio to use a specific environment when deploying on-premise , debugging or using DataSense to retrieve metadata from a SaaS provider, double-click to open your application’s mule-project.xml file, located in the root directory of your project.

    If you deploy your application to the cloud, right click on your application in the package explorer and select Deploy to Anypoint Platform → Cloud. Studio allows you to specify your environment variables prior to deployment, effectively enabling you to choose your deployment environment at runtime.

  7. Add an environment variable named mule.env with a value that matches the environment to which you wish to deploy by default (in the image below, the value is qa).

    runtime_env

  8. Close the mule-project.xml file, then save your application. When you debug your application or deploy it on-premise, Studio deploys to the environment you specified in the mule-project.xml file.

  9. To change the default deployment environment at any time, change the value of the environment variable key. For example, to deploy to a test environment – assuming you have a test.properties file in your application– change the value to test.

Deploying to a Specific Environment

Use the procedures below to deploy an application to a specific environment – production, qa, test, etc. – from Studio.

On-Premise

Studio

  1. In the Package Explorer, right-click the filename of the project you wish to deploy, then select Run As > Mule Application.

  2. Studio automatically deploys your application according the environment variable you specified in the mule-project.xml file in the procedure above.

Standalone

Identify the the environment in which to deploy your application at runtime with an environment variable. Execute the command to run your mule application as per the example below.

/.bin/mule -M-Dmule.env=production
$ mule -M-Dmule.env=production

CloudHub

  1. In the Package Explorer, right-click the filename of the project you wish to deploy, then select Deploy to Anypoint Platform → Cloud.

  2. Then enter your Anypoint Platform credentials and domain particulars

  3. Click the plus sign under "environment variables" to add a new environment variable. Set the Key of this new variable to mule.env and it’s value to the environment you wish to deploy to (QA in this example).

    deploy_cloudhub

  4. Click Finish to deploy.

    To learn more about deploying to test environments in CloudHub, access the CloudHub Sandbox Environments documentation.

Overriding Properties

To override some or all of the properties, create a my-mule-app-override.properties file and drop it in $MULE_HOME/conf.

Create the properties override file only in the environments where it’s needed and with only the properties that actually need to be overridden.

Here is a method of accomplishing this:

<mule xmlns="http://www.mulesoft.org/schema/mule/core"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xmlns:spring="http://www.springframework.org/schema/beans"
      xmlns:context="http://www.springframework.org/schema/context"
  xsi:schemaLocation="
      http://www.mulesoft.org/schema/mule/core
            http://www.mulesoft.org/schema/mule/core/3.6/mule.xsd
      http://www.springframework.org/schema/beans
            http://www.springframework.org/schema/beans/spring-beans-current.xsd
      http://www.springframework.org/schema/context
            http://www.springframework.org/schema/context/spring-context-3.0.xsd">
  <spring:beans>
    <context:property-placeholder
             location="classpath:my-mule-app.properties,
                       classpath:my-mule-app-override.properties" />
  </spring:beans>
</mule>

If your ops team can’t drop files in Mule’s directory hierarchy, the alternative is to configure the placeholder configurer to pick up the override file from a well-known location, as shown here:

<context:property-placeholder
         location="classpath:my-mule-app.properties,
                   file:///etc/mule/conf/my-mule-app-override.properties" />

See Also

  • Learn more about encrypting a properties file using the Mule Credentials Vault.

  • To learn more about deploying to test environments in CloudHub, access the CloudHub Sandbox Environments documentation.

  • Learn more about Properties Placeholders in Mule.

  • Learn how to proceed when deploying multiple applications with Shared Resources