On-Premises Deployment Model
Mule application deployment consists of two main aspects:
-
The Mule runtime engine instance
-
The Mule applications deployed to that Mule instance
When you deploy applications to CloudHub or to Anypoint Runtime Fabric, these services take care of the Mule runtime engine instances needed to run applications.
When you deploy applications on-premises, you are responsible for the installation and configuration of the Mule runtime engine instances that run your Mule applications. Because you have complete control of the on-premise instance (unlike with CloudHub or Runtime Fabric deployments), you must understand the characteristics specific to on-premises deployments.
Running Multiple Applications in One Mule Instance
One instance of Mule runtime engine can run multiple applications, enabling you to include the same namespaces within different applications that neither collide nor share information, which provides additional advantages such as:
-
You can break down a complex application into several Mule apps with their specific logic, and then deploy those several Mule apps in one Mule instance.
-
You can share configurations across multiple applications by using domains.
-
Applications can depend on different library versions.
-
Multiple versions of an application can run within the same Mule instance.
Application Package and Deployment
Mule runtime engine unpacks all applications at runtime, removes the original .jar
files inside the /apps
directory, creates a new folder for each application, and names each folder with the same name as the application file (minus the .jar
extension).
To confirm successful deployment, verify the following:
-
The status of the application in the console is
DEPLOYED
. -
An unpacked application folder exists in the
/apps
directory of your Mule instance: for example, forstockTrader.jar
,$MULE_HOME/apps/stockTrader
. -
An anchor file exists for a running app: for example,
$MULE_HOME/apps/stockTrader-anchor.txt
.
If you want to store your applications in a different location, you can store them on Unix-based systems by creating a symlink to your application directory from $MULE_HOME/apps
.
Application and Domain Deployment
All applications are deployed together within a domain. By default, your application references the default
domain, and no further configuration is required. You can see that the domain is deployed with the Mule app in the console:
If you’re deploying multiple applications to the same Mule instance, and the applications must share the same resources, you can create a common domain to define configurations that can be referenced by multiple projects. This practice enables you to expose different services in different projects through the same HTTP host and port without causing conflicts.
Application Hot Deployment
You can modify your Mule application’s configuration files and custom classes and reload the app without having to restart Mule. The system property mule.deployment.forceParseConfigXmls
must be set to true
to pull the changes from the Mule application’s configuration files. Note that if you modify your Mule application’s configuration files to force a redeploy, the validations that happen when the application is packaged aren’t executed.
Every three seconds, Mule checks for updated configuration files in the $MULE_HOME/apps
directory and, when it finds one, Mule reloads the configuration file and the JAR files in that application’s java
source directory.
If you start Mule and specify an app using the mule.deploy.applications
property, the hot deployment process works only for the specified app.
To reload an application, you can:
-
touch
the anchor file of that application. -
touch
or update any of the Mule configuration files declared in themule-artifact.json
file.
For example, if you want to modify one of your custom classes, make your changes to the custom class, copy the updated class to the java directory, and then touch
the anchor file.
Communication Between Mule Instances and the Management Pane
Mule instances run independently from the Management pane to execute integration logic and serve API requests. This architecture enables you to deploy Mule runtime engine strategically and ensures that it is not a bottleneck to communications.
When an event occurs that causes the Mule instances to become disconnected from the Management pane, the instances continue to run as designed to execute integration and serve APIs without interruption. However, new or updated policies are not pulled and updated until the connection is reestablished.