1. Overview

The SonarQube platform consists of four components:

1. A SonarQube Server starts three main processes:

• Web server for developers and administrators to browse high-quality snapshots and configure SonarQube instances

• Search Server based on Elasticsearch searches backwards from the UI

• Compute Engine server, responsible for processing code analysis reports and saving them in the SonarQube database

A SonarQube database to store:

• Configuration of SonarQube instances (security, plug-in settings, etc.)

• Quality snapshots of projects, views, etc.

Several SonarQube plug-ins are installed on the server, which may include language, SCM, integration, authentication, and management plug-ins

Run one or more SonarScanner s on a build/continuous integration server to analyze projects

2. Architecture

The following architecture shows how SonarQube integrates with other ALM tools and where to use the various components of SonarQube.

1. Developers code in their IDE and use SonarLint Run local analysis.

2. Developers put their code in their favorite SCM: git, SVN, TFVC, and so on.

3. Continuous Integration Server triggers auto-generation and executes the SonarScanner required to run SonarQube analysis.

4. The analysis report will be sent to the SonarQube server for processing.

5. SonarQube Server processes and stores the analysis report results in a SonarQube database and displays the results in the UI.

6. Developers review, comment, and challenge their issues through the SonarQube UI to manage and reduce technical debt.

7. The manager receives reports from the analysis.Ops uses the API to automate configuration and extract data from SonarQube.Operations personnel use JMX to monitor SonarQube Server.

3. About Servers

• The SonarQube platform cannot have multiple SonarQube servers (although the server can As a cluster Install) and a SonarQube database.

• For best performance, each component (server, database, scanner) should be installed on a separate computer, and the server computer should be dedicated.

• SonarScanners are extended by adding machines.

• All machines must be synchronized.

• The SonarQube server and the SonarQube database must be on the same network

• SonarScanners do not need to be on the same network as SonarQube Server.

• There is no communication between SonarScanners and the SonarrQube database.

4. Installation

Prerequisite environment requires k8s cluster and helm

helm pull stable/sonarqube
tar xvf sonarqube-3.2.7.tgz
vim sonarqube/values.yam

Set User and Password

helm install sonarqube ./sonarqube

#The reason for the error is that my cluster is version 1.16
Error: unable to build kubernetes objects from release manifest: unable to recognize "": no matches for kind "Deployment" in version "extensions/v1beta1"

grep -irl "extensions/v1beta1" sonarqube | grep deployment

grep -irl "extensions/v1beta1" sonarqube | grep deploy | xargs sed -i 's#extensions/v1beta1#apps/v1#g'

Perform the installation again

helm install sonarqube ./sonarqube

Error: unable to build kubernetes objects from release manifest: error validating "": error validating data: 
ValidationError(Deployment.spec): missing required field "selector" in io.k8s.api.apps.v1.DeploymentSpec

grep -irl "apps/v1" sonarqube | grep deployment

Modify the above files in turn.

vim sonarqube/templates/deployment.yaml

vim sonarqube/charts/postgresql/templates/deployment.yaml

vim sonarqube/charts/mysql/templates/deployment.yaml

Perform the installation again

pod needs to request pv, use hostpath here

cat pv/pv1.yaml 
apiVersion: v1
kind: PersistentVolume
metadata:
  name: sonarqube-pv1
spec:
  capacity:
    storage: 10Gi
  volumeMode: Filesystem
  accessModes:
  -  ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  hostPath:
    path: /helm/sonarqube/pv1

Wait a moment to see the pod status

Perfect end!