application not reachable when ingress is enabled

[crispysipper]

Hello,

I have zero experience with this application, but I am attempting to deploy mq with the default helm charts and want to use an ingress as we are deployed in AWS and use AWS LB Controller in conjunction with external-dns to automate our ingress/load balancer/DNS creations across all of our clusters.

I noticed that the ingress class is hardcoded as nginx within the ingress template here. Why is that? Anyway I was able to make some minor modifications to the templates and values and allow alb as an acceptable ingressClassName (which should be configurable from values.yaml)

I was able to achieve automated ingress and DNS builds and it all appears to be functional on the surface. However, no matter what configuration I provide to the ingress results in failed health checks to the backend application (attempts to reach the mq webconsole result in 502 Bad Gateway):

• if you enable TLS here and keep the path to /, ALB health checks fail with a 404

• if you enable TLS and change the path to /ibmmq/console/internal, ALB health checks fail with a 302 (why is Websphere attempting to redirect incoming SSL traffic?)

• disabling TLS, which is what we ultimately want to do as we terminate SSL at the ALB, always results in Unhealthy: Health checks failed

• if you attempt to use a different port all together (9443 being the default, I tried 9080 as I wanted to terminate SSL at the ALB), nothing works and I'm quite sure the application doesn't support initializing on an alternative port at all, at least when deploying containers through helm.

Within the pod logs, there is constantly this error regardless of ingress configuration or client SSL policy:

The SSL connection cannot be initialized from the <IP_ADDRESS> host and 9,443 port on the remote client to the <IP_ADDRESS> host and 54,724 port on the local server. Exception: javax.net.ssl.SSLException: The WebSphere server received an unencrypted inbound communication on a secure connection.  This does not indicate a problem with the WebSphere server. To resolve the issue, configure the client to use SSL or to connect to a port on the WebSphere server that does not require SSL

We have application stacks running on four clusters that all use this same methodology to automate ALB/DNS creation successfully.

Please advise.

[crispysipper]

I was able to get this working by refactoring the charts

changing the hard-coded service ports in the helm templates from 9443 (which enforces SSL and therefore doesn't support termination at the load balancer) to 9080 (or any alternate port should be fine)

so all references to 9443 in the templates are now set to 9080 in my chart structure

adding the following block to service-ingress.yaml

spec:
  ingressClassName: {{ .Values.route.ingress.webconsole.ingressClassName }}

removing this hardcoded value:
https://github.com/ibm-messaging/mq-helm/blob/main/charts/ibm-mq/templates/service-ingress.yaml#L34

adding the following to values.yaml to fix the hardcoded nginx value defined in service-ingress.yaml by default

route:
  ingress:
    webconsole:
      ingressClassName:

In my use case ingressClassName = alb

since health checks were also failing from the load balancer to the backend (regardless of above config changes or by using the defaults) I added the following annotations to my alb deployment:

        alb.ingress.kubernetes.io/healthcheck-protocol: HTTP
        alb.ingress.kubernetes.io/healthcheck-port: '9080'
        alb.ingress.kubernetes.io/healthcheck-path: '/ibmmq/console/internal'
        alb.ingress.kubernetes.io/target-type: ip

all of these were necessary to support using ALB and offloading SSL at the ALB and passing health checks (OOB root value / doesn't work and results in a 404 health check)

ensure this is set:

route:
  ingress:
    webconsole:
      tls:
        enable: false

[crispysipper]

do not close this issue - all of this needs to be addressed by the chart maintainers