This document discusses how Docker can be used to deploy Mule instances by creating Docker containers. It provides steps to create a Dockerfile to build a Docker image containing Mule ESB. The image installs Java, downloads Mule, extracts and configures it. Layers are created for each step and flattened into a single filesystem. The document suggests improvements like parametrized images and integrating Docker builds into continuous integration.

2.  Today in IT industry, everyone expects that the
environment in which we test the application
should be similar to the final deployment
environment as possible, if not identical.
 This can be achieved by automating the
deployment using Docker.
 In this blog, we would discuss about docker and
how it can be used to create a container and
deploy Mule instances. We would also notice that
it can be easy to repeat the same with no
additional effort.

3.  Docker allows us to package an application with
all of its dependencies into a standardised unit
for software development. Docker containers are
based on open standards allowing containers to
run on all major Linux distributions and
Microsoft operating systems with support for
every infrastructure. Docker containers wraps up
a piece of software in a complete file system that
contains everything it needs to run: code,
runtime, system tools, system libraries –
anything that can install on a server. This
guarantees that it would always run the same,
regardless of the environment.

4.  Each virtual machines includes the
application, the necessary binaries and
libraries and an entire guest operating system
– all of which may be tens of GB’s in size. If
we need 10 instances of MuleSoft ESB, then
we would have to replicate the complete set
up including the operating system for each
instance.

6.  On the other hand, Docker containers only
includes the application and all of its
dependencies, but share the kernel with other
containers. They run as an isolated process in
user space on the host operating system.
They are also not tied to any specific
infrastructure so the Docker containers run
on any computer, on any infrastructure and in
any cloud.

7.  There are various good articles on the internet for
getting familiarized with Docker. So we continue
under the assumption that the reader already has
some knowledge about Docker.
 In this blog, we will show on how to create a MuleSoft
ESB instance with docker. We will be using a
community edition of the runtime which can be
replaced with an enterprise version by using
appropriate file and updating the Dockerfile in use.
 Firstly, we need to create a Dockerfile which is a
script and is used to build a Docker base image. It
takes the package containing Mule standalone,
extracts the files, removes unnecessary content and
configures the ports of the Docker base image. This
Docker file can be seen as below:

8.  FROM ubuntu:14.04MAINTAINER
govind.mulinti@whishworks.comRUN apt-get updateRUN apt-get
upgrade -yRUN apt-get install -y software-properties-common#
install javaRUN add-apt-repository ppa:webupd8team/java -
yRUN apt-get updateRUN echo oracle-java7-installer
shared/accepted-oracle-license-v1-1 select true |
/usr/bin/debconf-set-selectionsRUN apt-get install -y oracle-
java7-installer# MuleSoft EE installation:# This line can reference
either a web url (ADD), network share or local file (COPY)ADD
https://repository-
master.mulesoft.org/nexus/content/repositories/releases/org/
mule/distributions/mule-standalone/3.7.0/mule-standalone-
3.7.0.tar.gz /opt/WORKDIR /optRUN echo
"6814d3dffb5d8f308101ebb3f4e3224a mule-standalone-
3.7.0.tar.gz"| md5sum -cRUN tar -xzvf /opt/mule-standalone-
3.7.0.tar.gzRUN ln -s mule-standalone-3.7.0/mule-standalone-
3.7.0 muleRUN rm -f mule-standalone-3.7.0.tar.gz# Configure
external access:# Mule remote debuggerEXPOSE 5000# Mule JMX
port (must match Mule config file)EXPOSE 1098# Mule MMC
agent portEXPOSE 7777# Environment and execution:ENV
MULE_BASE /opt/muleWORKDIR /opt/mule-standalone-
3.7.0CMD /opt/mule/bin/mule

9.  A Docker image is essentially a multi-layer file
system. Once the container is running, these layers
are flattened to create one cohesive file system.
Almost each line of our Docker file creates a layer
that is stacked on top of the layer created by previous
line.
 But that is not the final stage, there are more
improvements that can to be made. For example, we
may like to consider creating intermediate images to
improve their re usability which can be referenced
internally with the Docker files. The images given
below shows the possible hierarchy of Docker images
which can be reused for any client, the OS can vary:

11.  Here we are using a standalone community version due to restrictions of
enterprise version. If we plan to use the enterprise version then we need
to enhance the above docker script to use the required packages and
apply appropriate license.
 We can go a step further and integrate Docker builds into your
continuous integration build system, using Maven or Gradle. This way
Docker images are created as part of the build lifecycle, freeing
developers to concentrate on creating decent Mule applications.
 On a regular basis, we encounter promoting containers between various
environments, from development to test or from UAT to Production.
Each environment has specific configurations that need to be applied to
the application inside the container. Re-building the complete image,
each time we want to promote the application, defeats the purpose of
using containers. The solution is to build parametrised Docker images.
On the other hand, if the containers are changed often, for example
every code commit spins up a new Mule container, then the latter
approach would be preferable since clean-up file system is required
once the container is decommissioned.

12.  These images can be provided for testing teams to test is and those
would be the as is applications which would be available for production.
 Thinking of some scenarios, we can plan accordingly to have docker
images on production as well. By this approach we can provision the
services as micro services and that can be made available and updates
can be delivered with ignorable outages. Other benefits are;
 It should be easy to start a new instance when a need arises and discard
it if it is no longer required, should be able to adapt to changes rather
quickly and thus reduce errors caused by, for instance, peaks loads and
configuration changes.
 Scale out and increase the number of instances to which applications can
be deployed.
 Instead of running one instance of some kind of application server,
MuleSoft ESB in our case, on a computer, we may require multiple
instances to be partitioned, example: performance. High-priority
applications run on a separate instance whereas applications which are
less critical run on another instance.
 Enable quick replacement of instances in the deployment environment.
 Better control over the contents of the different environments.