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.
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.
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
To confirm successful deployment, verify the following:
The status of the application in the console is
An unpacked application folder exists in the
/appsdirectory of your Mule instance: for example, for
An anchor file exists for a running app: for example,
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
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.
You can modify your Mule application’s configuration files and custom classes and reload the app without having to restart Mule.
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:
touchthe anchor file of that application.
touchor update any of the Mule configuration files declared in the
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.
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.