SonarQube | Installing Custom Plugins

Background

In this post, we will be exploring on how to install custom plugins on a Kubernetes hosted SonarQube instance.

SonarQube Documentation on Installing Plugin

Install a Plugin

• According to the official SonarQube documentation, custom plugins can be installed via the method of “manual installation”.
• In summary, the process follows as such:

1. Download the plugin you want to install. The version needs to be compatible with your SonarQube version.
2. Put the downloaded jar in $SONARQUBE_HOME/extensions/plugins, and remove any previous versions of the same plugins.
3. Restart your SonarQube server.

• However, this method offers no layer of persistence. If your Kubernetes Pod crashes/container restarts, then your custom plugins will be missing from the directory.

Method 1: Mount via ConfigMap

• After building the custom plugin (.jar file), convert the contents into plaintext by making use of base64 encoding.
• Create the configmap on Kubernetes.

$ k create configmap custom-plugin --from-file=plugin.jar

• Thereafter, you will be able to refer this ConfigMap as a Volume in the Kubernetes Pod and mount it to the container as a volumeMount.
• You can leverage on the Helm Chart provided by SonarQube to achieve this.

helm-chart-sonarqube/values.yaml at master · SonarSource/helm-chart-sonarqube

Kubernetes subPath Examples | MountPath vs subPath Explained | GoLinuxCloud

• Note that subPath is used here. If only mountPath was used, you might run into an error that causes your pods to be in CrashLoopBackOff. This is because mountPath by default mounts the directory in mode 420, making the directory a “read only file system”. SonarQube pod performs some utility as part of the start up (such as installing base plugins in the same location) -> this cannot be achieved in the directory is read only.
• However, subPath volume mount has its limitations as containers are not able to receive configMaps update.

ConfigMaps

Method 2: Host the custom plugins in Nginx Server

• Another way to make this work is to host your own Nginx server within the Kubernetes cluster and expose it via a Service — so that the SonarQube pod is able to download from it.
• By doing this, you achieve better maintainability as you will be able to install plugins by leveraging the current helm charts.
• Make use of Storage Class. In my case, I am using the native Azure Kubernetes Service Azure Disk.

• Create a PersistentVolumeClaim (PVC)to reference the StorageClass.
• When the PVC is created and referenced to the StorageClass, a persistent volume (PV) will be bounded. This can be seen when you do a kubectl get persistentvolume.

• Create a deployment of Nginx server — this will host the .jar plugin files within the Kubernetes Cluster.

• Lastly, you would need to expose this deployment via a Service.

• Now, it is time to place the .jar file into the Nginx server. We will do this via kubectl copy

$ k cp F:/plugin.jar -n sonarqube-ep sonarqube-plugin-server-63gh5689v5-66nbt:/usr/share/nginx/html/plugin.jar
# Format follows as such:
$ k cp <filedirectory/filename> <namespace of server> <server pod name>:<location of plugin in container>/<filename>

• Because we have hosted this using a Deployment, now when the Pod gets spin up due to an outage, the .jar file still exists as we are using a Persistent Volume to persist the plugins.
• In addition, since we have exposed this service on port 21000, we would be able to access this file via this url: http://sonarqube-plugin-service.sonarqube-ep.svc.cluster.local:21000/plugin.jar
• All you need to do now is to utilise the existing Helm Chart values.yaml to install this plugin.