Microcks UI is not loading on behind Azure application gateway Ingress

[meyyazhagan]

I tried to deploy Microcks on AKS along with application gateway as an Ingress.
I could see all the pods are running and ingress is route the microcks requests to host.

Below are the log outputs,
POD status
NAME READY STATUS RESTARTS AGE
microcks-5f6d6dc94b-9p95p 1/1 Running 0 18d
microcks-keycloak-69985858b9-vg82r 1/1 Running 3 18d
microcks-keycloak-postgresql-bd87d8fc7-pz8sq 1/1 Running 0 18d
microcks-mongodb-59f64665c4-fctk5 1/1 Running 0 17d
microcks-postman-runtime-5bf9944956-wm4lr 1/1 Running 0 18d

Ingress microcks Annotations
Name: microcks
Namespace: XXX
Address: X.X.X.X
Default backend: default-http-backend:80
Rules:
Host Path Backends
XXX.org
/microcks/* microcks:8080 (172.16.1.126:8080)
Annotations: appgw.ingress.kubernetes.io/appgw-ssl-certificate: default
appgw.ingress.kubernetes.io/backend-path-prefix: /
appgw.ingress.kubernetes.io/request-timeout: 120
appgw.ingress.kubernetes.io/ssl-redirect: true
kubernetes.io/ingress.class: azure/application-gateway
meta.helm.sh/release-name: microcks
meta.helm.sh/release-namespace: XXX
Events:

In the depth dive, I came to know that the URL is redirection is not happening .
Meaning, the context path for Microcks need to be set to run the microcks behind the reverse proxy.

When hit the URL https://xxx.org/microcks/ and getting below exceptions.

Loading failed for the <script> with source “https://XXX.org/main.3bf80884829c016c441a.js”. microcks:15:1
Loading failed for the <script> with source “https://XXX.org/runtime.0b05ef57c964121efcc0.js”.

**Microcks path is missing in URL** 
URL suppose to be  https://XXX.org/microcks/runtime.0b05ef57c964121efcc0.js
but getting URL is https://XXX.org/runtime.0b05ef57c964121efcc0.js  (Microcks is missing)
Looks context path is taken correctly to load the JS & CSS.

Can anyone help me with more lights how to context path on Microcks application?
Seeking for support, please advise.

[lbroudoux]

Hi @meyyazhagan !

Thanks for raising this issue. Have you seen we've got a Zulip Chat (microcksio.zulipchat.com) where you can reach community and people may help you regarding your deployment question.

Anyway, I'm not accustomed to Azure Gateway but it seems to propagate the /microcks context path to the webapp. Is that correct ? Don't know what method you used to deploy Microcks but usually we're having ingress.kubernetes.io/rewrite-target: / annotation on Ingress to do URL rewriting and reaching the root context of webapp. Have you tried setting this ?

[meyyazhagan]

Thanks @lbroudoux for responding back to the query.

I'm using Helm chart to deploy Microcks on AKS.

Just to add clear note, I dont see any issue with Azure Application Gateway as it works for other application.
To give a check, tried to add rewrite annotation too but it doesn't work.

Wondering, if the context path can be set at application level instead of Ingress?

Also, modified the helm variable like below

microcks:
  url: XXX.org/microcks

keycloak:
  url: XXX.org/keycloak

Outcome of Helm status

helm status microcks
NAME: microcks
LAST DEPLOYED: Thu Dec 17 06:46:47 2020
NAMESPACE: XXX
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
Thank you for installing microcks.

Your release is named microcks.

To learn more about the release, try:

  $ helm status microcks
  $ helm get microcks

Microcks is available at https://XXX.org/microcks.

Keycloak has been deployed on https://XXX.org/keycloak/auth to protect user access.
You may want to configure an Identity Provider or add some users for your Microcks installation by login in using the     
username and password found into 'microcks-keycloak-admin' secret.

Kindly let me know if any other details required to debug.

[lbroudoux]

Ok understood ;-)

Right now we do not have planned this usage for microcks.url or keycloak.url. What we have in mind - and the usages we had seen so far - are more about setting this URLs with different hostnames. For example:

microcks:
  url: microcks.dev.XXX.org

keycloak:
  url: keycloak.qa.XXX.org

Currently it's not possible to setup the context of both component. They're both expecting traffic on the root context only.

[meyyazhagan]

Thanks @lbroudoux for adding more lights.

Hope to see the context path feature implementation in upcoming releases.

[lbroudoux]

Is this a blocker for you? Is there some limitation on the Azure Ingress controller that cannot make it use hostname for routing to microcks or keycloak components?

[meyyazhagan]

Different set of applications running in AKS and those will be routed over Application Gateway. Hence we wanted to have application name append with domian url like (https://dev.XXX.com/application_name)

Ideally, no dedicated limitation of application gateway side as one AppGW can serve multiple application endpoints and route the request based on path with same hostname.

[lbroudoux]

OK got it. Is it a blocker for you or are you able to circumvent this convention ?

Just thinking out loud: I think it could be possible to add something on the Microcks side but not sure you'll be able to have such a feature on the Keycloak side... which made the whole setup a bit wobbly...

[meyyazhagan]

It's kinda blocker for me at this stage and dont have any workaround either then setting context path on Microcks.

Hope to see some other response to get Microcks endpoint available along with AppGW.

[lbroudoux]

Have you tried to reach Keycloak admin UI and check if it's working properly? Or is it suffering from the same issue?

[meyyazhagan]

Same challenges in KeyCloak service too. URL redirection to parent hostname & path is not happening.
Probably, if we found the way to fix the context path mapped, then the request will be route accordingly and microcks will run behind the reverse proxy.

[devcovato]

Hi @meyyazhagan, AppGw Ingress Controller doesn't support rewrites. I had the same issues.
I've given up and moved to Nginx Ingress Controller.

[meyyazhagan]

Thanks for the note, @devcovato
I have overcome the issue by configuring the domain based routing in AppGw ingress instead of path based routing, which will have dedicated endpoint. Below are the snippet for ingress deployment.
And, it works well.

kind: Ingress
metadata:
  name: go-server-ingress-certificate
  namespace: test-ag
  annotations:
    kubernetes.io/ingress.class: azure/application-gateway
    appgw.ingress.kubernetes.io/appgw-ssl-certificate: "name-of-appgw-installed-certificate"
spec:
  rules:
  - host: www.contoso.com
    http:
      paths:
      - backend:
          serviceName: websocket-repeater
          servicePort: 80