System properties configuration methods

SonarQube utilizes system properties during startup, which are not stored in the database. These properties can be configured through:

• sonar.properties configuration file
  You can define system properties through sonar properties (sonar.*) stored in the sonar.properties file.
• Environment variables
  You can define system properties through environment variables.
• Command line
  You can define system properties in the command line used to start SonarQube.

The properties set through the command line have precedence over the environment variables which have precedence over the sonar.properties file.

See the list of sonar properties considered as system properties, along with the corresponding environment variables: List of system properties.

In a ZIP installation

The preferred method to manage system properties in a ZIP installation is to edit the sonar.properties file which is stored in <sonarqubeHome>/conf/sonar.properties where <sonarqubeHome> is the location where the SonarQube Server distribution has been unzipped.

To encrypt sensitive system properties stored in sonar.properties, see Encrypting senstive settings.

In a Docker installation

The preferred method to manage system properties in a Docker installation is to use the environment variables.

System properties can also be edited in the sonar.properties file which is stored in <sonarqubeHome>/conf/sonar.properties where <sonarqubeHome> is the installation directory of SonarQube Server within your container. This path is stored in the SONARQUBE_HOME environment variable. 

In a Kubernetes installation

In a Kubernetes installation, a few system properties are set through Helm chart parameters. For example, the Helm chart's parameter jdbcOverwrite.jdbcUrl corresponds to the sonar property sonar.jdbc.url.

If you need to set additional system properties, you can set them in the Helm chart through:

• Sonar properties
• Environment variables

In addition, system properties stored in external Secrets or ConfigMaps can be injected into the Helm chart.

Defining sonar properties

In the SonarQube Helm chart (values.yaml file), use the sonarProperties parameter as illustrated below. This creates a custom sonar.properties file within the Kubernetes cluster.

sonarProperties:
   sonar.log.level: DEBUG
   sonar.security.realm: LDAP
   ldap.url: ldaps://organization.com

To encrypt sensitive properties in the Helm chart, see Encrypting Helm chart sensitive data.

Using environment variables

In the Helm chart, you can define system properties through environment variables by using env:.

Injecting external Secrets or ConfigMaps

In environments where another tool, such as terraform or ansible, is used to provision infrastructure or passwords, configuration may be read, via environment variables, from existing Secrets and ConfigMaps. 

To do so, proceed as follows:

1. Create a ConfigMap (or Secret) containing key/value pairs, as expected by SonarQube.

apiVersion: v1
kind: ConfigMap
metadata:
  name: external-sonarqube-opts
data:
  SONAR_JDBC_USERNAME: foo
  SONAR_JDBC_URL: jdbc:postgresql://db.example.com:5432/sonar

2. Set the following in your values.yaml (using the key extraConfig.secrets to reference Secrets)

extraConfig:
  configmaps:
    - external-sonarqube-opts

Related pages

• List of system properties