Reading Time: 7 minutes

Containers are becoming the de-facto hosting platform from microservices to databases and everything in-between. Kubernetes has emerged as the primary container orchestration platform, and MuleSoft offers Anypoint RTF, a Kubernetes-based container orchestration platform to run APIs and applications at scale, providing elasticity. 

But there are many customers who use other container orchestration platforms standardized for their organization  that they would prefer to run Mule on. This blog will walk you through a tried and tested architecture for accomplishing this.

latest report
Learn why we are the Leaders in API management and iPaaS
Read reports

The ephemeral nature of containers presents challenges to managing Mule runtimes, applications, and APIs deployed in them. Every time a container is shutdown (planned or unplanned) the container gets terminated for good, thus ending the lifecycle of the Mule. This is in sharp contrast with classic Mule running on vm’s, where shutdown is a momentary pause. 

Containers present following challenges:

  • Mule runtime engine registration with Anypoint management plane.
  • Mule runtime engine deregistration.
  • Log retention and aggregation.
  • Policy enforcement on APIs.

A containerized Mule

Although there are several ways of containerizing Mule, the diagram above indicates a tried and tested approach for containerizing Mule, as it provides the best of both worlds. It ensures compliance with Twelve-Factor app for containers, and leverages all the API management benefits Anypoint Platform offers. 

How it works

  • User checks-in the code to source control system.
  • Jenkins (or any other CI) detects the change and builds the Mule deployable.
  • The subsequent CI step also packages the Mule app, Mule runtime, registration script, JDK, and OS into a Docker image
  • Jenkins deploys the fully packaged image onto Kubernetes/DockerSwarm.  
  • The Docker image gets booted and it executes the registration script, which is configured as the bootstrap entry point in the Dockerfile. 
  • The registration script registers Mule runtime engine with Anypoint Runtime Manager by executing a series of API calls.
  • Once the Mule runtime engine is completely started and registered with ARM, the API automatically gets discovered by Anypoint API Manager via API Auto Discovery. 

Advantages

  • This approach complies with Twelve-Factor app container principles.
  • Provide ability to manage Mule APIs, thus you reap all the associated benefits, like managing policies, API analytics, monitoring, and SLAs.
  • With this approach, you can manage Mule runtime engine and it’s entire lifecycle. 

Main components

Startup and registration script

This script is responsible for establishing the duplex connectivity with Anypoint Platform and starting the Mule runtime engine. This is the first command executed by container during startup thus binding to Mule process. Script invokes Anypoint Platform API to retrieve access code and perform runtime registration.

Shutdown script

The shutdown script is responsible for cleanup after container shutdown. Containers are ephemeral in nature, when they are shutdown, the specific instance of the container is terminated and a new instance comes in it’s place with a new containerID and IP.  Thus it’s imperative that the container is properly de-registered from the platform. Shutdown script takes care of de-registration and cleanup. The script needs to be executed via Kubernetes lifecycle hook.

Things to consider:

  • For security reasons, open only the necessary ports.  Best practice is to use 443 for your API and an additional JMX port. The Mule agent itself doesn’t need an inbound port. This also applies to what is bundled inside the image.
  • Except /logs and /conf folders rest of the Mule installation should be “READ-ONLY.”  This is very important to enforce immutability and prevent injection of external files.
  • Remember to add a valid Mule license file at the time of image build.
  • Container binds to one startup process. Hence keep the runtime registration and startup in one call stack.
  • Bundle one app per container.

Want to explore more?

MuleSoft professional service has implemented this solution successfully at many large enterprises. Reach out to us in the comment section below if you have questions.