This repository contains the code to build a Sonarqube Operator for Kubernetes, including Red Hat OpenShift Container Platform.
The Operator will create a PostgreSQL database and a SonarQube instance connected to the PostgreSQL database.
It is implemented on top of the Red Hat Operator SDK - in particular the Ansible Operator.
There is a script develop/operate.sh
which will download the prerequisites (operator-sdk etc.), build the operator artifacts from operator-sdk defaults, package and push the operator container image, deploy the artifacts to a Kubernetes cluster, and create a kind: Sonarqube
CR to deploy an instance. You should use the help page to look at what the various options do, but for the most part if you want to deploy SonarQube to a cluster directly from this repo you could run develop/operate.sh -d
.
Before running the script make sure to update the location of the container image to a repository you have access to. If you decide to build your own container image for the operator, make sure to update develop/operate.conf
with an updated container image location and add the -p
flag to operate.sh
.
The installation of the Custom Resource Definition and Cluster Role requires cluster-admin privileges. After that regular users with admin
privileges on their projects (which is automatically granted to the user who creates a project) can provision the SonarQube Operator in their projects and deploy instances of Sonarqube using the sonarqube.redhatgov.io Custom Resource. If you’ve installed the operator from the RedHatGov Operator Catalog Index on an OLM-enabled cluster, the SonarQube operator can be installed from the OperatorHub interface of the console.
Perform the following tasks as cluster-admin:
-
Deploy the CustomResourceDefinition, ClusterRole, ClusterRoleBinding, ServiceAccount, and Operator Deployment:
develop/operate.sh
-
Once the Operator pod is running the Operator is ready to start creating SonarQube Servers.
-
To deploy the above, and also one of the
config/samples/redhatgov_v1alpha1_sonarqube*.yaml
example CustomResources:develop/operate.sh --deploy-cr
-
To install the operator with RBAC scoped to a specific namespace, deploying a Role and RoleBinding instead of a ClusterRole and ClusterRoleBinding:
develop/operate.sh --overlay=namespaced --namespace=mynamespace
A SonarQube instance is deployed by creating a kind: Sonarqube
Custom Resource based on the SonarQube Custom Resource Definition. You can see some samples in the samples directory. If you’ve installed the operator from the RedHatGov Operator Catalog Index on an OLM-enabled cluster, Custom Resource creation can be done through the console UI with embedded documentation or a form view.
-
Write the definition to a file (e.g. sonarqube.yaml) and then create the SonarQube instance:
oc create -f ./sonarqube.yaml
-
The operator will first create the PostgreSQL database, wait until it is up and running and then create the SonarQube pod.
-
Validate that both pods (postgresql and sonarqube) are running before proceeding.
-
You can validate the existence of your SonarQube instance by querying for sonarqube objects:
oc get sonarqube
-
Get the Route for SonarQube (the PostgreSQL database is not accessible outside of the project):
oc get route
-
Use the hostname returned in your Web Browser to open the SonarQube UI (default User ID is
admin
with passwordadmin
).
Deleting a SonarQube instance and its associated resources is as simple as deleting the sonarqube object. If you created a SonarQube Custom Resource with metadata.name
of sonarqube-example
it suffices to run the delete command on that resource:
oc delete sonarqube sonarqube-example
The Operator adds ownerReference fields to all created objects - which means that deleting the sonarqube object also deletes all objects that have been created by the Operator.
In case you wish to uninstall the SonarQube Operator make sure that there are no more SonarQube instances running. Once all SonarQube instances have been deleted simply delete the operator and its resources with:
develop/operate.sh --remove
OLM uninstallation for OLM-based operators can be handled through the UI, or by deleting the Subscription
.
The Operator SDK makes heavy use of Kustomize for development and installation, but intends bundles to be generated for use in an operator catalog. This enables the Operator Lifecycle Manager, deployed onto your cluster, to install and configure operators with a simple kind: Subscription
object, instead of a large collection of manifests.
If you are using a registries.conf
change and/or ImageContentSourcePolicy mirror that covers quay.io/redhatgov images, you should not have to change anything.
To change the image sources for all necessary images to deploy the operator without such a policy, you need to have the following images hosted in a container repository on your disconnected network:
-
quay.io/redhatgov/sonarqube-operator:latest
-
quay.io/redhatgov/sonarqube:8.3.1.34397
-
Some PostgreSQL 10 image that either behaves like the Red Hat PostgreSQL 10 RHEL 8 image or the docker.io/library/postgres:10 image.
The places where you must update those sources are then, respectively:
-
The
kind: Sonarqube
custom resource manifest:spec.sonarqube.image.src
andspec.sonarqube.image.tag
should be updated -
The
kind: Sonarqube
custom resource manifest:spec.postgresql.image.src
andspec.postgresql.image.tag
should be updated
If you intend on using develop/operate.sh
it expects you to be in a development environment. Operator installation from this script therefore expects access to the internet. This comes with one extra concern: If kustomize
isn’t in your path, it tries to download it from the internet and save it locally into a .gitignore`d folder. If you intend on using `develop/operate.sh
to install the operator, you should also bring kustomize
and place it in the $PATH
of the user who will be running the script. Additionally, in order to install the operator with develop/operate.sh
you’ll need to make the following change:
-
develop/operate.conf
: IMG should point to the sonarqube-operator image in your environment