Immutable Infrastructure & Micro Services mit CoreOs, Docker und Dropwizard Part 1, Grafik

Dockerizing Mule ESB Enterprise



In the last years the industry has identified the demand in development and operation automation which led to a growing number of tools in this area. We have seen the industrialization of virtualization which made DevOps automation possible. The rise of provisioning tools such as Chef, Puppet or the newcomers Ansible and YADT. Hypervisor solutions to optimize and isolate bundled systems such as Docker or SmartOS or enterprise wide monitoring solutions such as AppDynamics or Nagios. All these different parts are subsumed up under the buzz word DevOps.

Now in the context of a project which required a development environment and a test environment for end-to-end system tests we had the need to create multiple MuleEE instances at once. The DevOps approach and tools were a natural choice. We decided to use Docker to resourcefully create multiple instances to keep the overhead in system tests as low as possible. During our research we only found Mule Community Edition Docker images for the creation of virtualized Mule instances. Hence my motivation arose to provide a enterprise version.

In this blog post we will depict how you can dockerize your own Mule ESB Enterprise for an enterprise environment, under the assumption that a proper license and MuleEE version is provided.

Related Work

There exist already two Docker images in the Docker Hub which provide a bundled image containing Mule ESB. Unfortunately they only contain the Community Edition:

Mule ESB infrastructure

In a Mule ESB enterprise deployment scenario we can have two types of nodes:

  • Standalone MuleEE nodes which provide the Mule ESB functionality and can be clustered for high availability
  • And a Mule Management Console node which provides an administration GUI for deploying, monitoring and managing the standalone MuleEE servers and it’s applications

As depicted in the following graphic, the MMC can be deployed separately from the standalone MuleEE servers. The deployed MMC Agent on the MuleEE servers will help the MMC to auto discover the available instances.


Caption 1: Architecture of the Mule Management Console (Source:

Extract from the documentation:

MMC-1 The Mule ESB instances monitored by MMC. These can be standalone or embedded instances, or clusters.
MMC-2The MMC agent contained in the Mule instance, which is responsible for:

  • facilitating data transfer between the Mule instance and the MMC
  • applying changes (i.e. thread pools, and configuration file changes) to the Mule applications
MMC-3The MMC instance, the Web-based interface that interacts with Mule through:

  • the MMC agent
  • JMX functionality exposed by Mule. (For more information on JMX management, see the JMX Management page)

The MMC instance is a Web application packaged as a WAR file that executes from within your Web servlet container (i.e. Tomcat, JBoss, etc.).

Build a Standalone Mule ESB Docker image

There are various good articles on the internet introducing Docker. Therefore we continue under the assumption that the reader already has some experience with Docker.

Building the Docker base image

We created a Dockerfile which scripts the build steps for a Docker base image. It first takes the trial distribution package containing MuleEE and MMC, extracts the files, installs a Mule license – which needs to be provided by the user -, removes unnecessary content and configures the ports of the Docker base image. This Dockerfile can be obtained from GitHub and a checkout will be assumed as a precondition.

Due to restrictions of the Enterprise version, the Docker image needs to be set up for individual usage beforehand. It is required to:

  • provide the Enterprise standalone server from Mulesoft. In this Dockerfile we asume the downloaded trial version from, located in the same folder as the Dockerfile.
  • provide the Enterprise license file from Mulesoft, located in the same folder as the Dockerfile.

Hence the prepared directory should look like this:

  • ./Dockerfile
  • ./
  • ./mule-ee-license.lic

Now we can build and tag the Docker base image:

docker build --tag="mule-ee" .

Image types

There are two ways now to use the Docker base image, depending on the overall scenario:

  • you can use the base images to startup and create – in a classical operations sense – multiple standalone Mule ESB instances and one MMC instance. These can be used as a cluster as usual with hot deployment over MMC etc.
  • or – which we recommend – create an Docker image for each Mule ESB application to isolate applications from each other and this way startup and create multiple standalone Mule ESB instances and one MMC instance. This might be a an option in a Micro Services or SOA scenario where you want more explicit control over your container. Please keep in this scenario your license in mind.

App specific container image

Based on the MuleEE Docker base image, an application specific image can be build. The corresponding Dockerfile can look like this, the concrete realization is passed on to the reader:

FROM                    mule-ee:latest
ADD                     mule-app/target/ /opt/mule-standalone-3.5.1/apps/

Build application specific Docker image:

docker build --tag="my-mule-app-image" .

Build a Mule Management Console Docker image

After building the base Docker image, we require a MMC specific Docker image.

As for the previous Docker image a Dockerfile was prepared which can be obtained from GitHub and again a checkout will be assumed as a precondition. Furthermore it is required to provide the Mule Management Console from Mulesoft. We asume the downloaded trial version from, located in the same folder as the Dockerfile.

Hence the prepared directory should look like this:

  • ./Dockerfile
  • ./

Afterwards we can build and tag the Docker image:

docker build --tag="mule-mmc" .

Testdriving the dockerized Mule ESB infrastructure

Now after the creation of both image types or a couple of application specific images we will take them out for a spin.

For example we start two standalone Mule ESB Enterprise instances:

docker run -t -i --name='mule-ee-node1' mule-ee
docker run -t -i --name='mule-ee-node2' mule-ee

To start an app specific image use the following command:

docker run -t -i --name='mule-app-nodeX' my-mule-app-image

And we start a Mule MMC instance:

docker run -t -i -p 8585:8585 --name='mule-mmc-node' mule-mmc

Notice: On OS X the VBox from boot2docker  requires port forwarding from the host -> VBox -> Docker

 boot2docker ssh -L 8585:localhost:8585

Now we can take a look on the running Docker instances and see two MuleEE nodes and the MMC node running:

cpoepke:mule-mmc cpoepke$ docker ps
CONTAINER ID        IMAGE               COMMAND                CREATED             STATUS              PORTS                                        NAMES
f77b8b2bcabd        mule-ee:latest      /bin/sh -c /opt/mul   2 days ago          Up 3 seconds        1098/tcp, 5000/tcp                           mule-ee-node2    
500499fa5054        mule-ee:latest      /bin/sh -c /opt/mul   2 days ago          Up 1 seconds        5000/tcp, 1098/tcp                           mule-ee-node1   
a23cfc4c9df0        mule-mmc:latest     /bin/sh -c /opt/mmc   2 days ago          Up 2 minutes        5000/tcp, 1098/tcp,>8585/tcp   mule-mmc-node

And as expected entering http://localhost:8585/mmc-3.5.1 we will land us on the MMC login screen. Furthermore we can now discover that our MuleEE nodes have been auto discovered by the MMC node. Hence this verifies that the connection between the nodes themselves is established:

MMC Mule ESB instances

Caption 2: The Mule Management Console showing the auto discovered MuleEE instances


In this blog post we have shown how a MuleEE Docker base images and a MMC Docker images can be created. These can be used to ease the creation of developer, test or even production environments depending on the development and operations strategy of your company.

I am looking forward to your comments and lively discussions!


  • Yamen

    Very nice Conrad! Something we are just now working on, so great timing.

    Do you have any feel yet for the overhead (probably memory only) of running ‘one Docker per app’ as opposed to ‘one Docker per container’? And in the ‘Docker per container’ scenario, have you decided whether to mount apps/conf/log directories to the host, or include in the container?

    These are the kinds of decisions we’re currently wrestling with, and it would be good to get some insight from someone who is there already.

    • Conrad Pöpke

      Good d’mate!

      Thank you for your comment.

      I think you should ignore the overhead and put the emphasis more on your Continues Integration/Delivery strategy and infrastructure landscape, because buying hardware resources is today not a issue. Depending on your strategy you can choose if you want to deploy your apps via the MMC (btw. there is a great Maven plugin for that) or by handling Docker containers.

      Regarding the mounting of log file directories I would prefer to use the log directory in the container which is isolated from other containers this way and use something like logstash or graylog2 to send your log messages to a central logging collector such as Elasticsearch with Kibana or something similar. Just take a look here.



Your email address will not be published.