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.
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:http://www.mulesoft.org/documentation/display/current/Architecture+of+the+Mule+Management+Console)
Extract from the documentation:
|The Mule ESB instances monitored by MMC. These can be standalone or embedded instances, or clusters.|
|The MMC agent contained in the Mule instance, which is responsible for:|
|The MMC instance, the Web-based interface that interacts with Mule through:|
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 mulesoft.com , 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:
Now we can build and tag the Docker base image:
1docker build --tag="mule-ee" .
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:
1FROM mule-ee:latest 2. 3. 4ADD mule-app/target/mule-app-1.0.0-SNAPSHOT.zip /opt/mule-standalone-3.5.1/apps/
Build application specific Docker image:
1docker 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 mulesoft.com , located in the same folder as the Dockerfile.
Hence the prepared directory should look like this:
Afterwards we can build and tag the Docker image:
1docker 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:
1docker run -t -i --name='mule-ee-node1' mule-ee 2docker run -t -i --name='mule-ee-node2' mule-ee
To start an app specific image use the following command:
1docker run -t -i --name='mule-app-nodeX' my-mule-app-image
And we start a Mule MMC instance:
1docker 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
1boot2docker 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:
1cpoepke:mule-mmc cpoepke$ docker ps 2CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 3f77b8b2bcabd mule-ee:latest /bin/sh -c /opt/mul 2 days ago Up 3 seconds 1098/tcp, 5000/tcp mule-ee-node2 4500499fa5054 mule-ee:latest /bin/sh -c /opt/mul 2 days ago Up 1 seconds 5000/tcp, 1098/tcp mule-ee-node1 5a23cfc4c9df0 mule-mmc:latest /bin/sh -c /opt/mmc 2 days ago Up 2 minutes 5000/tcp, 1098/tcp, 0.0.0.0:8585->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:
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!
Dein Job bei codecentric?
Agile Developer & Consultant (w/d/m)
An allen Standorten
Gemeinsam bessere Projekte umsetzen.
Wir helfen deinem Unternehmen.
Du stehst vor einer großen IT-Herausforderung? Wir sorgen für eine maßgeschneiderte Unterstützung. Informiere dich jetzt.
Hilf uns, noch besser zu werden.
Wir sind immer auf der Suche nach neuen Talenten. Auch für dich ist die passende Stelle dabei.