Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Automating Mule Multi-Cluster Deployment

DZone's Guide to

Automating Mule Multi-Cluster Deployment

Learn the performance and scalability benefits of a Mule multi-cluster environment, then learn how to set it up for automated deployments.

· DevOps Zone ·
Free Resource

Read why times series is the fastest growing database category.

Why Go to Mule Multi-Cluster?

There is a big challenge in Mule to improve the performance, on-demand scalability, and identify a faulty service when you are running multiple services in a single Mule container. For example, if you’re running more than 50 services in a single Mule cluster and one microservice has a memory leak, it’ll be very hard to identify that faulty service in the list. So, we need to separate all microservices into multiple groups based on their functionality and domains and then deploy to a multi-cluster environment.

This kind of application isolation will help us to improve the performance by horizontally scaling the infrastructure on-demand which reduces the downtime of the whole cluster.Image title

Automated Deployment in Mule Multi-Cluster

Another challenge in automating deployments to a Mule multi-cluster is identifying the actual cluster to deploy. This can be done using a config file with the deployment parameters. This config file will be parsed to identify the exact cluster to trigger deployment using MMC REST API.

For example, if you’re grouping microservices based on their functionality and domain, then you need to define parameters like domain name, cluster name, app name, and version to deploy in your config file. If your domain and cluster are not going to change often, then you can separate the config file like below where the domain and cluster name can be in one config file and the app name in a separate config file.

Cluster Config

{
 {
  “domain”: “inventory”,
  “cluster: : [“cluster1”]
 }
 {
  “domain”: “payroll”,
  “cluster”: “[cluster2”]
 }
 {
  “domain”: “utility”,
  “cluster”: “[cluster1”, ”cluster2”]
 }
}


App Config

{“
 inventory”: [{
  app: “stockservice”,
  version: “1.2 .0”,
  context: “stock / v1”
 }, {
  app: ”purchaseservice”,
  version: ”1.4 .0”,
  context: ”purchase / v2
 }],
 “payroll”: [{
  app: ”salaryservice”,
  version: ”1.4 .0”,
  context: ”purchase / v2
 }]
}


If developers want to deploy a new version of a microservice, they just need to update the appconfig.json. You can also come up with a basic script that will parse the config file and compare the currently deployed version using MMC REST API and if there is a difference in version, it will deploy the latest version into the specific cluster using the domain name from the cluster config file.

Load Balancing a Mule Multi-Cluster Environment Using F5

Mule services are used to serve TCP requests, and require load balancing to distribute the request among the clustered nodes. In a multi-cluster environment, you need to route the requests to the respective cluster where the app is deployed. You can achieve this using F5 iRules and data-groups. The way in which you group Mule instances in multi-cluster should be the same way in which you define multiple pools in F5 and create data-groups for each pool.

  1. Add the app context into its respective data-group.

  2. In iRules, get context from the requested URI, check it against the data group, and route the request to the respective pool.

You can also manage the data-groups automatically using a config file. If a Mule service serves TCP request then add the context parameter in the config file like we did above through a script, call the F5 REST API and update the data group. If you move the app between clusters you don’t have to update the F5 manually, it will automatically do that.

Pros

  • The config file will be a full blueprint of your deployment infrastructure, like which applications are deployed on which cluster

  • It is very flexible and helps you to customize your deployment in many ways.

  • With this model, we can deploy the app in a specific order and dynamically move the app between clusters based on the load by updating the config file.

  • Migrate the entire application in one go from the old environment to a new environment using the config file.

  • You can put the config file in your Git repo and track all the changes in the commit history, which helps you to roll back to prior versions easily.

Cons

Config file-based deployment can be tedious work for the dev, who would need extra monitors to keep track of all the versions, which can be fixed by having automated test cases to promote new versions using a Jenkins pipeline.

Learn how to get 20x more performance than Elastic by moving to a Time Series database.

Topics:
mule ,deployment ,automated deployment ,automation ,integration ,devops

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}