Nav

Deploying to Your Own Servers

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

Before you can deploy to a server, you must first install the Mule Runtime and then register it on the platform.

You can deploy a Mule application to a local server via:

This document describes the options on the Deploy Application page, which is identical in all of the cases above.

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

Additionally, you can also deploy to your servers through:

On the other hand, deploy an app to CloudHub, see Deploying to CloudHub.

You must avoid having dual management over one same server. When using Runtime Manager, other deployment and management methods and/or tools – MMC and manual deployment – must be avoided.

Deploying an Application

From Anypoint Platform

  1. Sign in to the Anypoint Platform or click Sign up on the sign on page.

  2. Click Runtime Manager:

    deploying to your own servers get to arm
  3. Click Deploy application:

    DeployAppFromConsole 

    Note: For more information on the Servers tab, see Managing Servers.
  4. The Deploy Application page opens:

    DeployAppFirstScreen 

From Anypoint Exchange

  1. From Anypoint Platform, select Runtime Manager.

  2. Click Applications, then click Deploy Application.

  3. Provide a name for your application.

  4. Select a deployment target from the drop-down list.

    The target must be a registered server, server group or cluster.

  5. Click Choose File, then select Import File from Exchange from the drop-down menu.

  6. Enter the name of your application in the search box.

    You can see a full list of applications in Anypoint Exchange. Your application should appear in the search results list.

  7. Select the application you want to deploy, then select a version from the drop-down list.

  8. Click Deploy Application.

The new application appears in the list of deployed applications in the Applications tab.

From Sandbox

If you created an application in a sandbox environment and tested it, you probably will eventually want to migrate it to production.

  1. Once logged into your Anypoint Platform account, go to one of your non-sandbox environments

  2. In the Applications tab, click the Deploy Application button

    deploying to your own servers d84f7

  3. Name your deployment, then select the deployment target. The target must be a registered server, server group or cluster.

    deploying to your own servers cb103

  4. Then when picking the application file, instead of uploading a new file, click Get from sandbox.

    deploying to your own servers 561b4

  5. This opens a window that displays all of your applications running in sandbox environments on servers on-premises, sorted by environment. Select an application and click Apply.

    deploying to your own servers 862c0

  6. Continue setting up your deployment as you would with any normal deployment.

Currently, only applications that are deployed to user-managed runtimes are displayed in this list. Applications deployed to CloudHub workers that are in sandbox environments can only be promoted to run on other CloudHub workers.

Also, be mindful of the Mule runtime versions being used by the servers in both environments. They should both use the same or at least compatible versions. See Updating Mule Versions.

Limitations

  • Keep in mind that if you’re deploying to a production target that is of a different type (ie: cluster vs single server) or that has a different Mule runtime version installed in it, there could be compatibility issues.

  • Only a user with permissions on both the sandbox environment and the destination production environment can move applications between them.

  • To avoid domain name conflict, an application cannot exist in two environments at the same time. Alter the application’s name slightly to deploy it to another environment.

  • Runtime Manager prevents you from having duplicate application names in a single environment. If a name is already taken, you will be prompted to provide a new name.

Creating an Application Name

Every application requires a unique application name. The application domain identifies your application in the Runtime Manager. Valid names contain alphanumeric characters and dashes, and contain at most 40 characters. If the name is valid, the Runtime Manager alerts you whether it is available or already reserved by another user.

DeployAppName

Deployment Target

If you already have servers registered to the Anypoint Platform, you will see a Deployment Target field that lets you specify where you want to deploy your application:

  • On the CloudHub worker cloud

  • On a server on-premises, in a different cloud repo, a server group, or a cluster

This document focuses on deploying to on-premises servers, for more information on deploying to CloudHub, see Deploying to CloudHub

Application File

Upload a new file for deployment. Click the Choose file button, select your application file, and then click Open. You can also click the Get from sandbox button to copy a file from a non-production environment into your current environment. (If the Get From Sandbox button does not appear, you may first need to create a non-production environment to view this option.) 

Note: The application file size limit is 100 MB.

ApplicationFile

Runtime Version

Since the server, server group or cluster you select implicitly has a single Runtime version installed in it, this is determined automatically by the server you select.

Keep in mind that servers in a cluster must have the same Runtime version installed in all of them.

Ensure that the runtime version in the server or servers is the same Mule version used to develop your application. For example, if you deploy to a server that runs Mule runtime 3.5.0 and your application uses the new HTTP connector introduced in Mule 3.6 and newer, your application won’t deploy and the log contains errors.

Insight Tab

The Insight tab lets you specify metadata options for the Insight analytics feature. For more information, see Insight.

deploying to your own servers c5057

Properties Tab

The Properties tab enables you to specify properties that the application uses during deployment and while running. Application properties are defined as key/value pairs.

deploy app properties tab

For example, you can define properties for db_user and db_password that specify credentials for connecting to a database.

Specifying properties in Runtime Manager enables you to define properties in one place rather than having multiple application property files for a single application in multiple environments. You can also define application-specific properties in a properties file, then later add environment-specific properties from Runtime Manager during deployment

After deploying an application, you can modify application properties or create new ones from the Application Settings page. The values of properties defined on this tab override any application properties defined in the mule-app.properties or other properties of the Mule runtime.

If you change properties after an application is deployed, you must restart the application and any server group or cluster where the application is deployed.

When deploying an application using the Get From Sandbox feature, your new application will inherit any properties defined in the original application. You can update these properties as required before deploying the application.

The following security considerations apply to these properties:

  • Values sent between Runtime Manager and the Mule runtime are encrypted over HTTPS.

  • Values stored in the Runtime Manager internal database are encrypted.

  • By default, Runtime Manager does not display the values of the properties in the UI.

  • Only users that have access to the Application Setting page can view these properties.

Logging Tab

Each Mule runtime stores log files in its respective local drive. The Logging tab of the deploy menu lets you configure how these logs are structured. Specifically, it lets you set how the different logging levels are applied (INFO, DEBUG, WARN, or ERROR), so that they don’t follow the default usage.

deploying to your own servers 198b4

Configuring this via the logging tab has the same effects as editing the log4j2.xml file on your Mule runtime. For details on how to do that, see see logging in Mule. You can also check a reference to log4j2 configuration in Apache’s documentation.

Configuring a Deployed Application

You can change the application file of a deployed application

  • Select your application in the Applications page to open its corresponding panel

  • Click Choose File to upload a new file

Keep in mind that your application will then experience a moment of downtime while the new version you just selected is launched in the server, server group or cluster.

Deployment Errors

If an error occurs and the application cannot be deployed, the application status indicator changes to Failed. You are alerted in the status area that an error occurred. Check the log details for any application deployment errors. You need to correct the error, upload the application, and deploy again.