My Bloody Sonar - An opinionated SonarQube Docker Image

Self Configured SonarQube Docker image based on Official SonarSource Images
(heavily influenced by My Bloody Jenkins and telia-oss/terraform-aws-sonarqube)

What's in the Box?

My Bloody Sonar is a re-distribution of the Official Docker image for SonarQube bundled with most popular plugins and ability to configure most aspects of SonarQube from a simple and single source of truth represented as YAML.

The image can get the configuration from several data sources such as: File, S3, Environment Variable, HTTP, Kubernetes ConfigMap and Kubernetes Secret.

The image supports "Watching" configuration changes and applying them immediately without restarting SonarQube.

Features

• Configuration Coverage:
  • pretty all settings under sonar.* properties namespace
  • ldap.* properties, although full application of it might require a restart of web engine.
    (therefore Environment variables is recommended)

Why Use the term "Bloody"?

As original quote says:
"The term "My Bloody SonarQube" came from the fact that I tried to put all my "battle" experience, (i.e. blood, sweat and tears) within the image. I just thought it is a "catchy" name for this kind of a repository." (c) Ohad David
I thought these epithets is also pretty suitable for this custom SonarQube image.

Demo and Usage Example

A demo can be found here

Releases

Docker Images are pushed to Docker Hub

Each release is a docker tag v$VERSION-$RELEASE where:

• VERSION is the SonarQube app version
• RELEASE is a release e.g. lts, community, developer, enterprise

For each git tag, there following tags will be created:

• $VERSION-$RELEASE - one to one relationship with git tag
• $RELEASE - latest version for that release variant.
• lts - represents the latest lts release

get the LTS release (openjdk:11-jre-slim) alternative tags: lts

docker pull mslipets/my-bloody-sonar:lts

get the latest community version (alpine) alternative tags: 8.7.0-community, community

docker pull mslipets/my-bloody-sonar:latest

get the latest developer version (alpine) alternative tags: 8.7.0-developer, developer

docker pull mslipets/my-bloody-sonar:developer

get the latest enterprise version (alpine) alternative tags: 8.7.0-enterprise, enterprise

docker pull mslipets/my-bloody-sonar:enterprise

get a concrete 8.7.0-developer release

docker pull mslipets/my-bloody-sonar:8.7.0-developer

Environment Variables

The following Environment variables are supported

Besides all Environment variables supported by Official Docker image for SonarQube

• SONAR_ADMIN_USERNAME - (mandatory) Represents the name of the admin user. If LDAP/SAML is your choice of authentication, then this should be a valid IDP user id. If using own Database, then you also need to pass the password of this user within the configuration.

Bare minimum to be set is:
SONAR_ADMIN_USERNAME
SONAR_ADMIN_PASSWORD
SONAR_JDBC_USERNAME
SONAR_JDBC_PASSWORD
SONAR_JDBC_URL
SONAR_BASE_URL

• SONAR_ADMIN_ADDRESS - Define the SonarQube admin email address

• JAVA_OPTS_* - All JAVA_OPTS_ variables will be appended to the JAVA_OPTS during startup. Use them to control options (system properties) or memory/gc options. I am using few of them by default to tweak some known issues:

• SONAR_ENV_CONFIG_YAML - The configuration as yaml. When this variable is set, the contents of this variable can be fetched from Consul and also be watched so SonarQube can update its configuration everytime this variable is being changed. Since the contents of this variable contains secrets, it is wise to store and pass it from Consul/S3 bucket. In any case, before SonarQube starts, this variable is being unset, so it won't appear in SonarQube 'System Information' page (As I said, blood...)

• SONAR_ENV_CONFIG_YML_URL - A comma separated URLs that will be used to fetch the configuration and updated SonarQube everytime the change. This is an alternative to SONAR_ENV_CONFIG_YAML setup. Supported URLs:

  • s3://<s3path> - s3 path
  • file://<filepath> - a file path (should be mapped as volume) - can be a file, folder or glob expression (e.g. file:///dir/filename or file:///dir or file:///dir/*.yml)
  • http[s]://<path> - an http endpoint

Note: If multiple URLs are passed, or the file url contains a dir name or a glob expression, all yaml files are being deep merged top to bottom. This behavior enables to separate the configuration into different files or override default configuration.

• SONAR_ENV_CONFIG_YML_URL_DISABLE_WATCH - If equals to 'true', then the configuration file will be fetched only at startup, but won't be watched. Default 'false'

• SONAR_ENV_CONFIG_YML_URL_POLLING - polling interval in seconds to check if file changed in s3. Default (30)

//TODO: * SONAR_ENV_PLUGINS - Ability to define comma separated list of additional plugins to install before starting up.

This is option is not recommended, but sometimes it is useful to run the container without creating an inherited image.

Configuration Reference

The configuration is provided in yaml format, each node with value is corresponds to sonarqube property (can be lookup on gui) or in sonar.properties file.

Each key is responsible for a specific aspect of SonarQube configuration.

Credits

• Ohad David for My Bloody Jenkins
• Telia OSS for aws-env and terraform-aws-sonarqube
• SonarSource for original docker-sonarqube

License

Licensed under either of

• Apache License, Version 2.0 (LICENSE-APACHE or http://www.apache.org/licenses/LICENSE-2.0)
• MIT license (LICENSE-MIT or http://opensource.org/licenses/MIT)

at your option.

Contribution

Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in the work by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any additional terms or conditions.