Prerequisite and Requirements:
Knowledge to create MSR image and push to image repository like docker hub.
Make sure the ingress controller is deployed on the Kubernetes cluster (for eg, nginx-ingress-controller). Setting ingress controller is outside the scope of this documentation. Please refer to ingress controller (for eg nginx-controller) documentation for this. Make sure the nginx controller is exposed as loadbalancer service or a nodeport service. Sample template to expose nginx controller as a NodePort service is shown below.
sampleYamlFiles.zip (1.9 KB)
Please refer to ingressservice1.yaml in the attached zip file
Note: Make sure to use correct labels, name, selector and namespace to match your environment. In my setup, ingress controller was using app=ingress-nginx label and is present in ingress-nginx namepsace. This will expose nginx-controller as a nodeport service (Perform this only if your ingress controller is not exposed as a service).
To obtain the nodeport port -
kubectl -n ingress-nginx get services nginx-ingress
Steps to configure path based routing
In this setup, I will be using 2 MSR images which will be used in 2 deployments. Based on the path, request should be routed by ingress to correct MSR
For eg
http://IngressHostName/abc/ → point to MSR1
http://IngressHostName/xyz/ → point to MSR2
To deploy MSR, please refer to the attached deployments templates (2 deployment templates for 2 MSR)
deploymentofMSR1.yaml and deploymentofMSR2.yaml are present inside the attached zip
You can apply the deployment template using kubectl apply -f deploymentofMSR1.yaml. You will have to run this individually for 2 deployments. Make sure to update the template with correct image url.
Now create 2 services (type ClusterIP) to expose the MSR running on pods.
Service1 – expose the pods with label type=myis1 (name= myis-service1, type=ClusterIP, port=1111, targetPort=5554)
Service2 – expose the pods with label type=myis2 (name=myis-service2, type=ClusterIP, port=2222, targetPort=5554)
service1.yaml and service2.yaml are present in the attached zip folder.
You can apply the template using kubectl apply -f service.yaml. You will have to run this individually for 2 services.
Create an ingress resource which will set the rules (host, paths – path-service). The ingress should have the following annotations
nginx.ingress.kubernetes.io/rewrite-target
nginx.ingress.kubernetes.io/use-regex
This ingress resource defines 1 rule with 2 paths pointing to 2 different services (which in turn points to different MSR running in different pods)
ingressResource.yaml is present inside the zip attached
You can update the template to add your hostname, paths etc. Template can be applied using
kubectl apply -f ingressResource.yaml
Use the node port 30625 to access nginx. If you have exposed nginx as loadbalancer service then you can use the dns of the loadbalancer instead.
Test and Validate:
Now you can invoke services using the paths configured in the ingress resource for eg.
http://IngressHost:NodePort/abc/invoke/pub.math:addInts?num1=2&num2=3
http://IngressHost:NodePort/xyz/invoke/pub.math:multiplyInts?num1=2&num2=3
To validate if the requests are routed to correct MSR, you can run the run the following to obtain the diagnostic data and check ServerAbout.txt.
http://IngressHost:NodePort/abc/invoke/wm.server.admin:getDiagnosticData
http://IngressHost:NodePort/xyz/invoke/wm.server.admin:getDiagnosticData
Note:
Path-based routing to access IS admin UI is only supported in MSR via the new admin UI. It will not work with the old admin UI. This statement is not valid if you just want to access services directly without access to Admin UI. How to default to new admin UI – Set watt.server.defaultPackage=WmAdmin and then create docker image to include this change. This new image should be used in the deployment templates.
Open 2 browsers (for eg chrome and edge). Using the same browser can cause issues as the same sessionid will be passed in different requests. Else you need to cleare cache and cookies if you want to use the same browser.
Use the URLs which you configured in the ingress to access MSR1 and MSR2. For eg
Validate if the request was navigated to correct MSR by noticing the host name on upper right corner of the screen.
The main focus of this effort was to test UI and SOAP-based webservices. User needs to find a way to expose the soap based webservices endpoint urls. wsdl from the package will contain endpoint url that was configured during design time and It will be missing the information regarding the path configured in ingress. As setting up of path is done on ingress and is a runtime activity, there is no way to update the endpoint in the wsdl and users need to find a way to share the endpoint (containing the path configured in ingress) among concerned parties.