Sonarqube deployed via helm; Stuck on “Loading…”

Version -
sonarqube:10.7.0-community

Helm Chart - 10.7.0+3598

Sonarqube is deployed via Helm.

I am trying to install sonarqube on AWS EKS cluster and installing it in the exact same manner which is followed in this issue ticket as well LTS deployed via helm; Stuck on "Loading..."
Moreover I am not using any plugins yet, also defining path as “/*” as suggested in above blog but still I just see Loading…

Also my values.yaml file looks like

apiVersion: helm.toolkit.fluxcd.io/v2beta2
kind: HelmRelease
metadata:
  name: sonarqube
  namespace: sonarqube
spec:
  releaseName: sonarqube
  chart:
    spec:
      chart: sonarqube
      version: 10.7.0+3598
      sourceRef:
        kind: HelmRepository
        name: sonarqube
        namespace: flux-system
  interval: 5m
  install:
    remediation:
      retries: 3
    crds: CreateReplace

  upgrade:
    crds: CreateReplace
  
  values:
    replicaCount: 1
    elasticsearch:
      # DEPRECATED: Use initSysctl.enabled instead
      configureNode: false
      bootstrapChecks: false
    ingress:
      enabled: true
      #className: alb
      annotations:
        kubernetes.io/ingress.class: alb
        #ingressClassName: alb
        alb.ingress.kubernetes.io/ssl-redirect: "443"
        alb.ingress.kubernetes.io/healthcheck-path: /
        alb.ingress.kubernetes.io/listen-ports: '[{"HTTPS": 443}]'
        alb.ingress.kubernetes.io/load-balancer-attributes: access_logs.s3.enabled=true,access_logs.s3.bucket=xxx-xxx-yyy-aaa-logs
        alb.ingress.kubernetes.io/scheme: internal
        alb.ingress.kubernetes.io/security-groups: sg-1234,sg-5678
        alb.ingress.kubernetes.io/ssl-policy: ELBSecurityPolicy-TLS-1-2-2017-01
        alb.ingress.kubernetes.io/success-codes: "200,303,301"
        alb.ingress.kubernetes.io/target-type: ip
      hosts:
        - name: sonarqube.xx.k8s.yy.io
          #path: /*
          paths:
            - path: /*
              pathType: ImplementationSpecific
              #pathType: Prefix
    ## Override JDBC values
    ## for external Databases
    jdbcOverwrite:
    # (DEPRECATED) Please use jdbcOverwrite.enabled instead
    # enable: false
    # If enable the JDBC Overwrite, make sure to set `postgresql.enabled=false`
      enabled: true
      # The JDBC url of the external DB
      jdbcUrl: "jdbc:postgresql://xx-yyy-db-eks.ct1234.us-east-1.rds.amazonaws.com/sonar?currentSchema=public"
      # The DB user that should be used for the JDBC connection
      jdbcUsername: "sonar"
      # Use this if you don't mind the DB password getting stored in plain text within the values file
      jdbcPassword: "sonar"
    
    postgresql:
    # Enable to deploy the bitnami PostgreSQL chart
      enabled: false
    
    readinessProbe:
      exec:
        command:
        - sh
        - -c
        - |
          #!/bin/bash
          # A Sonarqube container is considered ready if the status is UP, DB_MIGRATION_NEEDED or DB_MIGRATION_RUNNING
          # status about migration are added to prevent the node to be kill while sonarqube is upgrading the database.
          if wget --no-proxy -qO- http://localhost:{{ .Values.service.internalPort }}{{ .Values.readinessProbe.sonarWebContext | default (include "sonarqube.webcontext" .) }}api/system/status | grep -q -e '"status":"UP"' -e '"status":"DB_MIGRATION_NEEDED"' -e '"status":"DB_MIGRATION_RUNNING"'; then
            exit 0
          fi
          exit 1
      initialDelaySeconds: 60
      periodSeconds: 30
      failureThreshold: 6
      # Note that timeoutSeconds was not respected before Kubernetes 1.20 for exec probes
      timeoutSeconds: 1

    livenessProbe:
      exec:
        command:
        - sh
        - -c
        - |
          wget --no-proxy --quiet -O /dev/null --timeout={{ .Values.livenessProbe.timeoutSeconds }} --header="X-Sonar-Passcode: $SONAR_WEB_SYSTEMPASSCODE" "http://localhost:{{ .Values.service.internalPort }}{{ .Values.livenessProbe.sonarWebContext | default (include "sonarqube.webcontext" .) }}api/system/liveness"
      initialDelaySeconds: 60
      periodSeconds: 30
      failureThreshold: 6
      # Note that timeoutSeconds was not respected before Kubernetes 1.20 for exec probes
      timeoutSeconds: 1
    
    startupProbe:
      initialDelaySeconds: 30
      periodSeconds: 10
      failureThreshold: 24
      # Note that timeoutSeconds was not respected before Kubernetes 1.20 for exec probes
      timeoutSeconds: 1
    

What have I tried so far to achieve this?

  1. I created a sonarqube kubernetes namespace.
  2. I have deployed an external RDS postgres database dedicated to hosting the sonarqube database (and a security group which allows 5432 port traffic from the sonarqube autoscaling group private subnets) and I believe the sonarqube pod is connecting to the External Database without any issue.
  3. The kubernetes cluster has an AWS Load Balancer Controller v1.7.1 deployed which manages AWS Application Load Balancers to satisfy kubernetes ingresses. It looks like this configuration is all working properly.
  4. I configured a Route 53 A record pointing my desired url hostname to the application load balancer that was configured by the Kubernetes ingress.
  5. I have a customized helm chart values.yaml which I attached above and I installed the helm chart using fluxcd.

Sonarqube is working on localhost on port forwarding but its not loading with ingress.
Though my ingress setup is consistent along with my other applications which are working as expected.

When I inspect on chrome browser I see below error

Failed to load resource: the server responded with a status of 404 ()Understand this errorAI
outIIC4BPOF.js:1 
        
        
       Failed to load resource: the server responded with a status of 404 ()Understand this errorAI
outAPPHAF2J.css:1 
        
        
       Failed to load resource: the server responded with a status of 404 ()

Also I see similar behaviour on other browsers as well like Safari.

Could someone from the community help here as this issue is completely blocking me.

Thanks

I would really appreciate some help with this issue. Or any kind of direction for debugging more into this which I may be missing would also be helpful. @jeremy.cotineau @ganncamp

Thanks

Hey there.

Please don’t tag individuals not involved in a thread, as outlined in our FAQ.

I created a topic, when can I expect a response?

This is an open community with people volunteering their free time to provide assistance. We’re eager to contribute to the community, but you are not guaranteed a fast response.

Be patient

  • Wait a few days before bumping a topic that hasn’t received a response.
  • Do not @name mention individuals not involved in the topic.
1 Like

Could someone from the community help here as this issue is completely blocking me.

Thanks

Could someone from the community help here as this issue is completely blocking me.

Thanks

Hello @Anurag_Jain thanks a lot for the detailed explanation, it helps a lot.
Considering that the port-forward works and it looks like a browser ressource access issue, could i ask you to share your ingress config ?

On top of that it might be linked to the sonar.core.serverBaseURL property, could you try to set it up with a value like:

  sonarProperties:
    sonar.core.serverBaseURL: your url
1 Like

Thank you so much for your response @jeremy.cotineau .

I did set the below property via UI (on port forward )because in helm chart default values there is no option to set this (commented out). sonarqube 10.8.1 · sonarsource/sonarqube

sonarProperties:
    sonar.core.serverBaseURL: your url

Event after setting this property and even after pod restart , UI is still in loading state for me.

Please find below the ingress settings -

  values:
    replicaCount: 1
    elasticsearch:
      # DEPRECATED: Use initSysctl.enabled instead
      configureNode: false
      bootstrapChecks: false
    ingress:
      enabled: true
      #className: alb
      ingressClassName: alb
      annotations:
        #kubernetes.io/ingress.class: alb
        #ingressClassName: alb
        alb.ingress.kubernetes.io/ssl-redirect: "443"
        #alb.ingress.kubernetes.io/certificate-arn: arn:aws:acm:us-east-1:12345:certificate/111-222-333-111-222
        alb.ingress.kubernetes.io/healthcheck-path: /
        alb.ingress.kubernetes.io/listen-ports: '[{"HTTPS": 443}]'
        alb.ingress.kubernetes.io/load-balancer-attributes: access_logs.s3.enabled=true,access_logs.s3.bucket=xxx-aaa-ccc-alb-logs
        alb.ingress.kubernetes.io/scheme: internal
        alb.ingress.kubernetes.io/security-groups: sg-aaa,sg-bbb,sg-ccc,sg-ddd
        #alb.ingress.kubernetes.io/subnets:  subnet-aaa,subnet-vvvv,subnet-bbb,subnet-ccc,subnet-ddd,subnet-eee
        alb.ingress.kubernetes.io/ssl-policy: ELBSecurityPolicy-TLS-1-2-2017-01
        alb.ingress.kubernetes.io/success-codes: "200,303,301"
        alb.ingress.kubernetes.io/target-type: ip
        alb.ingress.kubernetes.io/tags: env=aa,ss=xx,app=sonarqube
      hosts:
        - name: sonarqube.aaa.k8s.bbb.io
          #path: /*
          paths:
            - path: /*
              pathType: ImplementationSpecific

Please let me know in case any further details needs to be shared.

Thank you
Anurag

thanks a lot for the configuration snippet, everything looks indeed correct even if i have never personally tested and configured an ingress with all those alb specific annotations.

I would suggest first we try to identify precisely which request / endpoints are in error, could you share the anonimized details of a network capture in your browser ? the goal is to see if we have some redirection or resource url issues on specific endpoints.

Also can i ask if you are behing a corporate proxy ? because infinite loading is something we experience sometimes with such security misconfig.

After this i would suggest to try a simpler ingress config approach if that is possible on your side, stripping down almost all annotations and tls (if its a test instance that will be trashed / recreated )

1 Like

@jeremy.cotineau Please find the below required details

Network capture , PFA the image

And when I check network config on localhost its passing through as attached.

When I am doing curl and telnet with the route 53 entry , I am getting proper response so the proxy is working fine, I think. and this is the base ingress setting I am using to setup the load balancer which we use everywhere.

Thank you
Anurag Jain

hmm very interesting, we can try to move one layer above, could you do a port-forward again, but not on the sonarqube pod but on the ingress service itself ?

Then try to access it this way by passing the host header you defined in the ingress when accessing localhost.

Also, i would like to know if the request does reach SonarQube or not. Do you have anything in the access_logs of the pods ? you can exec in the pod and look for logs/access.log as i think those are not aggregated to stdout by default.

Thank you @jeremy.cotineau for your help with this issue. I issue was with my load balancer, the ingress which I was defying wasn’t getting picked up properly by load balancer. Re-checked it yesterday thoroughly and got that issue.

Thank you
Anurag Jain

perfect, glad to hear that, could you share how you identify this and managed to fix it ? as it could help other users in the future.

Thanks again for the nice discussion, and for your contribution in the community.

So , When you asked for network capture yesterday, and it wasn’t working for my ingress but was working on localhost, that’s when it clicked could be some issues with listener rules in routing.
And helm deployment wasn’t picking up my config of path : /* and it was picking up only path : / . default value seems. And that’s how got the solution.

Thank you for your help for routing me in this direction.

1 Like