How to set up a Persistence Gateway for Mulesoft Runtime Fabric

If you’re new to Runtime Fabric you might be wondering if it provides the Object Store functionality that we use for our apps in Cloudhub.
The answer is YES! Applications deployed to Runtime Fabric can use an Object Store and it can even be persistent. For that, we need to provide a PostgreSQL database that will serve as the data source of our Object Store in RTF.

To enable this functionality Runtime Fabric needs to deploy what we call a Persistence Gateway. This persistence gateway is an intermediate layer between your apps in Runtime Fabric and the PostgreSQL database. 

The cool thing about it is that the applications using the Object Store Connector, which means using the Object Store v2 REST API, don’t have to change anything to use the Persistent Gateway. The Persistent Gateway can translate the OS queries into postgres queries. This is very important for us, Mule Architects and Developers, because this works as a layer of abstraction. So, in a nutshell, the same code using the OS connector will work on Cloudhub and in RTF.

In our previous post, we learnt How to Deploy PostgreSQL to Kubernetes. After that, once we’ve got our PostgreSQL database up & running, we’ll configure our Runtime Fabric (RTF) instance to use it as the persistence storage for our Mule apps.

For that, we need to create a couple of K8s resources within the runtime fabric namespace where the RTF services are running:

• A Secret - where we’ll store the connection string to our PostgreSQL database

• A Custom Resource - In Kubernetes, a Custom Resource (CR) is an extension of the Kubernetes API that allows you to define and manage custom types of objects. Custom Resources allow you to extend Kubernetes's native capabilities by adding your own resource types, beyond the standard resources like Pods, Services, and Deployments. In this case, we'll create a PersistenceGateway custom resource to tell Runtime Fabric how to connect to our PostgreSQL and some extra configuration options.

Let's see how to create those resources:

Create Secret

To create the K8s secret run the following:

kubectl create secret generic [SECRET_NAME] -n [RTF_NAMESPACE] —from-literal=persistence-gateway-creds='postgres://username:pass@host:port/databasename'

Where:

• SECRET_NAME - It’s the secret we created in the previous step
• RTF_NAMESPACE - This is the namespace where you’ve installed initially Runtime Fabric. This is where the mule agent is running. We normally name it rtf, but double-check it.
• username, pass, port and databasename - these are the parameters to connect to our database that we defined in the previous post
• host - This is the hostname of the postgreSQL instance. In our case, that corresponds to the Service endpoint we created to expose postgreSQL. Here we’ve got two options:
• We can use the IP address associated to the postgres Service. We can get that by running the command below. The IP should be under the Internal IP column

kubectl get services -A

• Although using the IP would work and we can do it for a quick test, that’s not the recommended option as the IP would change everytime the service is updated/recreated
• A better way to get the host value is to use the DNS of the postgres service. Notice that, in our example, the service is deployed in a different namespace, so we’ll have to use the FQDN:

service-name.namespace-name.svc.cluster-domain.example

• The default cluster domain is cluster.local. So, in the postgres instance we created in the previous post, the host value would be

postgres-service.postgres.svc.cluster.local

• Remember not to change the flag --from-literal=persistence-gateway-creds It has to be specifically that value.

Create Custom Resource

We’ll use the template below to create the Custom Resource for the Persistence Gateway. Create a file called mule-persistence-gateway-crd.yaml and copy the content:

apiVersion: rtf.mulesoft.com/v1

kind: PersistenceGateway

metadata:

name: default

namespace: rtf

spec:

objectStore:

backendDriver: postgresql

maxBackendConnectionPool: 20

replicas: 2

secretRef:

name: rtf-pg-secret

resources:

limits:

cpu: 250m

memory: 250Mi

requests:

cpu: 200m

memory: 75Mi

• Where:
• kind - It’s the type of resource. This value is PersistenceGateway and cannot be changed
• metadata
• name: default - This works as an identifier for the custom resource. No need to change it
• namespace: rtf - This is the namespace where RTF services are deployed. Normally it’s rtf, but double-check it
• objectStore:
• backendDriver - The driver used to connect to the DB. This has to be postgresql, don’t change it
• maxBackendConnectionPool - This is the maximum number of simultaneous connections the persistence gateway can establish to the database. Don’t change it unless your applications require a heavy use of the Object Store and you identify this as a bottleneck
• replicas - It’s the number of pods that will be running the persistence gateway. Put a minimum of 2 for High Availability. Consider adding more, depending on the number of nodes in your cluster
• secretRef - this is where we tell the Persistence Gateway to use the secret we created with the connection string
• Resources - This section specifies the minimum and maximum CPU/Memory that the Persistence Gateway can take from the K8s cluster. It’s important to set these limits so that an unexpected or heavy use of the Persistence Gateway does not consume too many resources that would compromise the performance of the whole RTF instance
• limits - The maximum CPU/memory to be allocated
• requests The minimum CPU/memory to be allocated
• Create the CR:

kubectl apply -f mule-persistence-gateway-crd.yaml

Verify the installation was successful

Now, let's check that our resources were created successfully and that our Persistence Gateway can connect to our Postgres instance.

• First, run the command below to check that the replicas of the Persistence Gateway are up & running

kubectl get pods -n rtf

• Copy the name of the pod(s) running the Persistence Gateway and get the logs

kubectl logs persistence-gateway-7b6c9f95d8-rghtl -n rtf

• If you see the Successfully connected message that means the connection between the Persistence Gateway replicas to your database is working
• Lastly, go to the Anypoint control plane and Runtime Manager > Runtime Fabrics and click on your RTF instance. You should now see that there is a new item added to the Health Details tab for Persistence Gateway

Testing the Persistence of your Persistence Gateway

In our next post, we'll create a Mule app that stores and consume the Object Store and we'll deploy it to Runtime Fabric. We'll then see if the data persists after restarting the app and also how the key/value pairs are stored in the postgres database. That'll be fun!