Run Sonarqube in Kubernetes using helm chart

In this blog I will explain how I configured Sonarqube in kubernetes as a deployment (replica set).

Sonarqube provides helm chart for its different editions (Community edition,Developer edition, Datacenter edition). We can deploy Sonarqube as stateful application or a replicaset. Both options are available in the values.yaml file of the helm chart. Helm chart can be download from this link:

https://SonarSource.github.io/helm-chart-sonarqube

Sonarqube helm charts are versioned and we can install it according to our requirement. Current latest chart version is 9.6.3 (sonarqube-9.6.3). We need to remember that this version is only for helm chart release and the docker image version is different from this. We can verify it from either Chart.yaml (appVersion) or from values.yaml

Once we get the desired helm chart, we need to modify the values.yaml file to match with our infra. I tried with both Community edition and Developer edition. And I used deployment instead of stateful set since my requirement does not needed persistence for sonarqube and the parameters which I modified were as below,

        deploymentType: "Deployment"
        edition: "developer"
        resources:
          requests:
            memory: 2Gi
            cpu: 2
          limits:
            memory: 4Gi
            cpu: 4
        image:
          repository: sonarqube
          tag: 9.9.0-{{ .Values.edition }}
          pullPolicy: IfNotPresent
        service:
          type: ClusterIP
          externalPort: 9000
          internalPort: 9000
          labels:
        ingress:
          enabled: true
          hosts:
            - name: sonar.example.com
              paths: 
                - path: /
                  pathType: Prefix
        prometheusExporter:
          enabled: false
        jdbcOverwrite:
          enable: true
          jdbcUrl: "jdbc:postgresql://custom-sonar-postgres:5432/sonarqube_db?socketTimeout=1500" 
          jdbcUsername: "sonarqube"
          jdbcSecretName: "sonar-psql-monitor"
          jdbcSecretPasswordKey: "sonar_password"
        postgresql:
          # Enable to deploy the PostgreSQL chart
          enabled: false
        account:
          adminPasswordSecretName:: "admin-pw"
        livenessProbe::
          initialDelaySeconds: 300
          periodSeconds: 90
          failureThreshold: 6
          timeoutSeconds: 30
          sonarWebContext: /
        monitoringPasscodeSecretName: "sonar-psql-monitor-pass"
        monitoringPasscodeSecretKey: "monitoring_password"

Once the values file modification completed we can deploy the helm chart using below to command:

helm install --create-namespace sonar sonarqube ./sonarqube

If you have a CICD process configured in your infra, you can integrate the helm chart into that deployment chain with necessary modification. For example, you only need to override the necessary parameters for values.yaml if you have a proper deployment tool stack.

NOTE: Use kubernetes secrets instead of maintaining the plain text passwords in values.yaml and refer the secret and key using the parameter options in the same.

Issues faced
When we tried with Community edition as a replicaset deployment, it was restarting the pod due to liveness probe failures. Even though we tried slight increase of values for the probes, it was not succesfull. On checking with Sonarqube forums the conclusion we got as, we need to run it either as a Statefulset or else as a Deployment with persistent storage. This is because of the elastic index which creates while bootstrapping the container. If there is no persistent storage these index creation and update will take more time and the probe will expire within the time frame.

But this issue never faced in Developer edition when we tried as a replicaset deployment which is our actual requirement. Even though we were analysing both versions, Developer edition was working fine with same resource configurations and default probe configuration. To use it as part of the regular builds we need to purchase the license. Sonarqube license is for the whole system and the number of lines of code we will scan using Sonarqube. We won’t be able to run some projects with license and some without license in the same Sonarqube.

Further Steps
We were needed to integrate Sonarqube with Jenkins as part of CI pipeline. After installation we need to create a user and token for this.

Once the user created we can configure the sonarqube integration in Jenkins. For this, log into Jenkins as an administrator and go to Manage Jenkins > Configure System. Scroll down to the SonarQube configuration section, click Add SonarQube, and add the values you’re prompted for. The server authentication token should be created as a Secret Text credential.

We can then configure our source code repo integration in Sonarqube for code analysis. This can configure under Sonarqube > Administration > Devops Platform Integrations . For more info please refer: https://docs.sonarqube.org/9.6/devops-platform-integration/github-integration/

For authentication and user management we can either use Sonarqube native user management mechanism or we can use centralized authentication methods using source code management tools or any SAML integrations,

Once it is done we are good to go. We can create projects in Sonarqube for respective repos and we will be able to the source code analysis as part of the CI process.