Initial setup of Runtime Fabric on an AWS OpenShift Dedicated cluster




This is post number 5 on the series of How to Install Runtime Fabric on OpenShift Dedicated in AWS. In the previous posts:


In this post, we'll set up the Runtime Fabric instance to make it available for our Mulesoft environments and expose it for external traffic. We will:
  • Associate Business Groups and Environments
  • Install an Ingress Controller (NGINX)
  • Configure the Ingress Resources Template for Runtime Fabric
  • Test - deploy an app
Let's go step by step:

Associate Environments

In this step we make our Runtime Fabric instance available for our Anypoint environments. We can associate our RTF instance to one or multiple Business Groups and we can even select the specific environments on those Business Groups where we want to make RTF available to deploy apps.

The best practice here is to have different RTF clusters for Production and Non-Production environments. That'll guarantee a minimum of isolation.

For that, from the home page of our RTF instance click on the Associated Environments tab and select the Business Groups first and the environments of that Business Group after.


Install an Ingress Controller (NGINX)

  • In order to make our apps accessible from outside the K8s cluster we need to install an Ingress Controller. There are multiple options for that - NGINX, AWS LB, Traefik... In this tutorial, we’ll install NGINX, which is the most popular.
  • From your web browser, navigate to https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.1.0/deploy/static/provider/aws/deploy.yaml. You’ll get a long response in yaml format with the definition of multiple K8s objects (namespace, roles, deployment, services...). Those are all the K8s resources required for the NGINX installation. Copy the content of all of that to the clipboard or a text file.
  • From the Cluster management console, click on the plus icon located in the top right corner. This is the option for creating K8s resources for your cluster using a yaml file. Paste the previous content and click create.
  • One of the resources that we’ve just created is a LoadBalancer Service. That’s the K8s service that maps the external endpoint of the cluster (the public DNS name of a Network Load Balancer) to the replicas running the ingress controller.
  • For the next step, we need to find out the public DNS of our Load Balancer. We can get that by running the following command in our terminal
oc get service -n ingress-nginx
  • From the outcome of the command, copy the DNS name of the LoadBalancer service.

Configure the Ingress Resources Template for Runtime Fabric

Every time we deploy an application to our Runtime Fabric, we need to create an Ingress for that app. That Ingress contains the routing rules to be applied by the ingress controller of our K8s cluster. For example, if we deploy a hello-world app, we need to create an ingress that routes the traffic to http://my-domain/hellow-world/my-endpoint to our app in the cluster.

We don't have to do this manually for each app we deploy. Fortunately, Runtime Fabric Services allows us to create a template that will be applied on each deployment.

On this tutorial, we'll use a very simple ingress template, with a path-based rule to route the traffic to the hostname/app-name path.

There might be extra configurations to be added on this template, depending on the ingress controller we're using. Custom configurations are defined in the annotations section of the ingress manifest. In this tutorial, we'll be using an annotation for NGINX to make our rule work as expected. For that we'll follow the next steps:
  • Go to Networking > Ingresses and click Create
  • Remove the content of the ingress example and copy the following text. In the host field we need to provide the public DNS of the load balancer that we retrieved in the previous step
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/configuration-snippet: |
rewrite ^/app-name(/|$)(.*) /$2 break;
name: rtf-ingress-template
namespace: rtf
spec:
ingressClassName: rtf-nginx
rules:
- host: [PUBLIC_DNS_NAME_OF_INGRESS_CONTROLLER]
http:
paths:
- path: /app-name
pathType: ImplementationSpecific
backend:
service:
name: service
port:
number: 80
  • If you get the error:
Error "failed calling webhook "validate.nginx.ingress.kubernetes.io": failed to call webhook: Post "https://ingress-nginx-controller-admission.ingress-nginx.svc:443/networking/v1/ingresses?timeout=10s": no endpoints available for service "ingress-nginx-controller-admission"" for field "undefined".
  • There’s a workaround, which is deleting the Validating Webhook or opening port 8443 from master to pods (it’s a workaround, I still don’t know why this happens... yet!). For that, you’d run
oc delete ValidatingWebhookConfiguration -n ingress-nginx ingress-nginx-admission
  • After that, try to Create the Ingress again, it should work now
  • Now, if we go to our Runtime Fabric page we should see the Inbound Traffic set up:

Deploy an app

Finally, our RTF setup is complete, we only need to deploy a simple app to verify everything works.
    • Go to Runtime Manager > Applications and click on Deploy Application
    • Provide a name for your app and select our RTF cluster in the Deployment Target dropdown
    • Upload the jar file of a valid mule app. For testing purposes you can choose to Import a Hello World app from Exchange (provided by MuleSoft)
    • Click on the Ingress tab and verify that the public point to be created is correct.
    • Click on Deploy Application and wait. Your app should be ready in a few seconds
    • Lastly, test your app and verify you can hit successfully your endpoint(s)
    Congratulations, you’ve successfully installed and setup your Runtime Fabric on an AWS OpenShift Dedicated cluster!
    Previous Post Next Post