Customizing Helm chart
This page explains how to perform the most important customization of the Helm chart for SonarQube Server’s Data Center Edition (DCE).
While we only document the most pressing Helm chart customizations in this documentation, there are other possibilities for you to choose to customize the chart before installing. See the Helm chart README file and Customize the chart before installing documentation for more information on these. In particular, see the recommended production use case values.
You can customize the Helm chart:
By editing the default values in the
values.yaml
file.Or directly in the Helm chart installation command line if installing from the Helm repository (see Installing from Helm repository).
Enabling Openshift
If you want to install SonarQube Server Helm chart on Openshift:
Set
OpenShift.enabled
totrue
.Set
Openshift.createSCC
tofalse
.If you want to make your application publicly visible with Routes, you can set
route.enabled
totrue
. Please check the configuration details in the Helm chart documentation to customize the Route based on your needs.
Ensuring a restricted security level
Securing communication within the cluster
You can secure communication within the SonarQube Server cluster by using mutual TLS. A secure connection can be set up at two different layers:
Between search nodes.
Between application and search nodes.
Securing communication between search nodes
To establish a secure connection between search nodes:
Securing communication between application and search nodes
In order to secure the communications between the application and search nodes:
Secure the communication between search nodes as described above.
Set
nodeEncryption.enabled
totrue
.
Creating an Ingress to make SonarQube Server service accessible from outside
To make the SonarQube service accessible from outside of your cluster, you most likely need an Ingress.
The SonarSource Helm chart has an optional dependency on the NGINX Ingress Helm chart which installs the NGINX Ingress controller (To install the NGINX Ingress Helm chart through SonarQube Server DCE Helm chart, set ingress-nginx.enabled
to true
in DCE’s values.yaml
.). You should use it only in a test environment. In a production environment, it’s highly recommended that you use your own Ingress controller since the controller is a critical part of the software chain.
To create an Ingress resource through the Helm chart:
Add the following to your DCE’s
values.yaml
. In this configuration, we use the Ingress class NGINX with a body size of at least 64 MB since this is what we recommend.
ingress:
enabled: true
# Used to create an Ingress record.
hosts:
- name: <Your Sonarqube FQDN>
# Different clouds or configurations might need /* as the default path
path: /
# For additional control over serviceName and servicePort
# serviceName: someService
# servicePort: somePort
annotations:
nginx.ingress.kubernetes.io/proxy-body-size: "64m"
Printing logs as JSON strings
SonarQube Server prints all logs in plain text to stdout/stderr. It can print logs as JSON-String if the variable logging.jsonOutput
is set to true
. This will enable log collection tools like Loki to post-process the information provided by the application.
About persistence in Elasticsearch
SonarQube Server comes with a bundled Elasticsearch. As Elasticsearch is stateful, it makes sense to persist the Elasticsearch data for Data Center Edition (DCE) clusters because the cluster will survive the loss of any single search node without index corruption. Persistence is enabled for the DCE by default and managed with the Helm chart.
Disabling persistence would result in a longer startup time until SonarQube Server is fully available which can be a very large factor considering the downtime for the index rebuild on DCE clusters.
Last updated
Was this helpful?