Mulesoft RTF — A Brief Hands-on Guide

9 min readSep 2, 2022

Introduction

In this article, I will try to dive into MuleSoft RTF. The paper will explain how to install RTF in a Self-Managed Kubernetes cluster. It's a plus point if you have knowledge of Docker & Kubernetes.

Things you will need

The below softwares you will need for this hands-on:

Minikube or Kind
Kubectl

Article navigation

I will divide the article into the following parts:

Setup local k8s cluster
Setup RTF
Application Deployment
Testing the application

Setup local k8s cluster

We are going to use a local k8s cluster for the demonstration and exploring internal stuff. For the demonstration purpose, I have opted for Minikube. Definitely, you can go for Kind or even a production-grade cluster installation.

I’m not going to enter details of the Minikube installation for the sake of brevity and will start directly from cluster creation.

My cluster is very simple. Single node cluster created by the below command.

Note that I am allocating the maximum amount of CPU and RAM of my machine to the cluster. You can provide some cool numbers for the configs. It's up to you. After execution of the command, a single node cluster is created for you.

This is what happens in the pictorial view:

Minikube allocates a VM inside my machine and all the pods, services, deployments, ingress, etc will run inside this VM. Cool!!!

Let's do some cool stuff with the cluster with kubectl. Please check this documentation on how to install kubectl.

Check node information

Execute the below command to check the node information.

kubectl get nodes -o wide

Check Service CIDR

Now we are curious to know about the range of IPs Minikube will allocate for the k8s services. Let's find it out too by executing the below command:

kubectl cluster-info dump | grep service

Below is the snapshot of the output.

Check that service CIDR is 10.96.0.0/12. Now we are here:

So cool, right? Well, that's enough to know for this tutorial. Regarding Ingress, I will cover it in another article otherwise it will be very long :)

Setup RTF

This is the simplest thing I have ever done in my life. The official Mulesoft documentation is just enough for it. However, I will highlight the things I did for this demonstration.

First of all, you must have an official license from Mulesoft. Otherwise, you can not proceed.

Download MuleSoft License

First, you need to download your MuleSoft license. Check this link on how to download the license.

Download the license and store it in a file named license.lic (can be any name but with .lic extension.
Base64 encode the new Mule .lic license file provided by MuleSoft in your machine. For macOS execute the below command:

BASE64_ENCODED_LICENSE=$(base64 -b0 license.lic)

Done!

Get the RTF Activation code from the Anypoint Platform

Once we have our license in hand, the next step is to get the activation code for RTF. To get it, let's create an RTF.

And then let's choose the GKE,

You can choose AEK or AKS. It's up to you. Even though I am installing on my local machine, this option is still valid. What you need is just a k8s cluster and that's it.

Once done you will be presented with the activation data as shown below.

There are two ways you can install the RTF. Either Helm or RTFCTL. RTFCTL is a proprietary tool created by MuleSoft which is nothing but a layer above Helm. Internally, it uses Helm. So no secrets.

RTFCTL installation

The official documentation is enough for this part. Check it out here.

RTF Installation

This is so easy. Make sure that your k8s cluster is up & running. Then execute the below command:

rtfctl install <activation_data>

That's all. It will download all the necessary k8s artifacts from repositories and launch a series of pods and services in a k8s namespace called rtf.

You can even keep an eye on what's happening by executing the below command:

kubectl get all -n rtf

After a couple of minutes, all artifacts will be installed and you can see something like this.

Well, if you are not a command line lover definitely there is an option. Let's execute the beautiful dashboard provided by Minikube by executing the below command.

minikube dashboard

Voilá!!! Check it out. Freaking cool!!!!

You can explore the dashboard and I will leave this for you while I focus on the command line. Cool!

You don't need to care too much about what all these pods & services of MuleSoft are doing. What we will focus on next is our application deployment.

Configure the License

Hope you remember that in the very first step, I downloaded the MuleSoft license and put it in a system variable called: BASE64_ENCODED_LICENSE.

Now, after RTFCTL installs the necessary k8s artifacts we need to install the license in our k8s cluster. For that execute the below command:

rtfctl apply mule-license $BASE64_ENCODED_LICENSE

This command does nothing more than create a k8s secret in the namespace rtf. Let's check this out also:

You can even check the content of the secret but it makes no sense as it's an encoded one.

Application Deployment

After a while, you will see a happy green button saying that your RTF is ready to work.

The ideal is to create the RTF in the root Organization and then assign business groups and environments to use the RTF.

We are good till this phase. Now, to deploy an application you must choose the RTF we have configured as shown below:

Let's check some more information regarding the RTF here.

You might remember that when I created my minikube cluster I executed:

I put CPUs and memory as MAX. That's why you can see in the previous diagram that the maximum allocable vCPU for the Mule app is 8 vCPU (my CPU) and the maximum memory is 14.6 GB that's my RAM.

Cool, right? Now, let's proceed with my deployment. I configured the below for my deployment:

A new namespace is created

Your application gets deployed in a new namespace:

This is nothing but the environment ID.

Check pods

Let's check the pod created for my application named hello.

This pod named hello-79646c8bd5-ljg4p contains 2 active containers running in it. Technically, there run 3 containers but one of them is used only for initiating the application. Once done this pod gets deleted.

Check deployment artifacts

Now, you might ask where are those configurations regarding the vCPU & memory, etc, and who is managing the pods. It's the deployment stereotype of k8s.

When I deployed my hello mule application a deployment artifact is also generated. You can check it:

Now we can even check what's inside it:

kubectl describe deploy hello -n 62e5548c-f7a8–4b41-a058–0883e83a1d99

It will exhibit a lot of information. I will focus on the important ones.

The containers

I told you that 3 containers are initialized in the pod. Check them

Init Container:

The first one is the init container:

Its function is to do some initialization work and once done it's gone.

2. app container

Here is our actual hello application container bundled with the Mule 4.4 runtime.

You can even check the resources in the Limits & Requests sections.

3. anypoint-monitoring container

It's a container that keeps updating our Control pane i.e the Anypoint GUI with changes in the pods etc.

This is so cool. Right?

Check services

There is more cool stuff. Let's check the service created.

Do you remember the service CIDR we were checking at the beginning of the article? Check that the IP of the service falls under the CIDR 10.96.0.0/12

If you want to know what a Service is you can check this documentation. In short, Service is the abstraction that exposes the service running in pods. So, it might be quite tempting to execute the endpoint:

http://10.98.34.192:8081/api/v1/hello

But, it will not work. Why?

Note that the TYPE of the hello service is ClusterIP. And I am trying to execute it from my MacBook i.e outside of the cluster. That's why it won't work.

Testing the application

Now, when you click the Mule app in the Runtime Manager there is a wtf moment.

How should I access my application? There is no URL

The answer is obvious. I did not configure Ingress and that's why the application is not accessible outside of the cluster.

But, there is always a hack.

The hack

What about changing the type of the service to NodePort?

Let's do it. You can do it either from the console or from the dashboard. Execute the below command:

kubectl edit svc hello -n 62e5548c-f7a8–4b41-a058–0883e83a1d99

Change the ClusterIP to NodePort and save it by pressing !wq. Now list out the k8s services.

Check that the service TYPE has been changed to NodePort and in the PORT(S) section there are some port mappings added.

The meaning of the NodePort type is that now the service will be accessible on any node of my cluster on port 30787 for HTTP and so on. Do you still remember the IP of my cluster node/s? I have only one node with IP 192.168.64.21.

Let's check if we can invoke my application.

Wowww!! It worked. That's enough for today.

Conclusion

In this article, I have tried to explain the RTF in a very simple way. I did not configure Ingress for the application deployed and that's why I had to open ports on the node(s) on the cluster to access it. The ideal way is to configure an Ingress for the applications. I will cover this part in the next article. Until then, happy learning. There is no secret!