As Integral Ad Science (IAS) continues to scale globally, the wide array of software products and services it develops evolve and become more complex. The risk of incidents related to application failure and bugs being leaked into production increases. To mitigate this, we need an authority that consistently monitors the code for potential bugs and detects them at a very early stage of development.

This article showcases how at IAS, we adopted GitOps to host SonarQube in a Kubernetes cluster.

Why did IAS decide to run Sonarqube as a production service?

Borrowing an anonymous software testing quote —

A bug in hand is worth two in the box.

Programmers aren’t perfect. The extent of manual code review is limited, and every error in the code will never be found. The relative cost in terms of developer time and effort of fixing issues in production because of errors in the code is high. It is much easier to fix them while the developers are still in the coding phase. Here is an example of a very costly error —

July 22, 1962: NASA’s Mariner 1 Done In by a Typo

Code quality is important as it impacts the overall software quality, which is critical. SonarQube is a great tool that can consistently monitor the code for bugs and security vulnerabilities and offers visual feedback to the developers in a dashboard.

Architecture Overview

The entire architecture is divided into three separate processes that are implemented in the following order:

1. Sonarqube Helm Chart
2. Configure Database
3. Deploy to Cluster

Sonarqube Helm Chart

The official Helm webpage describes Helm as a package manager for Kubernetes, but it is more than that. Helm not only packages the application as a collection of pre-configured Kubernetes resources, but it also provides CLI commands that can be used to manage, deploy, upgrade, rollback, and delete the application in the cluster. In other words, instead of individually deploying Kubernetes resources like pods, services, rs (ReplicaSet), deployments, etc., we could deploy all resources using a single command helm install ; it’s that easy.

The application container image and Kubernetes resources required by that application are bundled together into a chart. At IAS, we decided to use open-sourced Sonarqube Helm chart maintained by Oteemo.

Configure Database

The above architectural diagram shows the high-level flow of provisioning Sonarqube’s supporting infrastructure, which is a PostgreSQL database (db) setup using AWS RDS (Relational Database Service) in the IAS Prod Environment.

The Sonarqube Helm chart provides an option to deploy the application along with a PostgreSQL database in the cluster, but we decided to use an external server. We wanted to take advantage of features like HA (Highly Available), easy to administer, and restore the database from snapshots.

The architecture consists of two different pipeline flows. The first one starts when the tag pipeline of git repository sonarqube-cdk-repository is triggered manually. sonarqube-cdk-repository is a GitHub repository that holds AWS CDK definitions for the PostgreSQL database and its secrets. The diagram shows the pipeline stages, and a numeric symbol labels their order.

Pipeline 1

① Provision Database using AWS RDS

We implemented a simple sonarqube AWS CDK construct that configures the following properties and provisions an RDS instance.

• DB credentials: Two database password configs are created, pg-admin-user-pw for the admin user and pg-sonar-user-pw for sonarqube. Both passwords are randomly generated and encrypted. They are stored in AWS Systems Manager’s Parameter Store (ssm param store).
• DB Engine type: db_engine sets a PostgreSQL version as the database engine.
• DB security group config: The same security group assigned to the AWS EKS cluster is used to allow communication between the sonarqube server and database.

② Bootstrap the DB

Once the database is provisioned, we need to bootstrap or do the initial setup so that Sonarqube can talk to it. This is done as part of the second pipeline stage. The sonarqube database username and password are grabbed from the parameter store, a database connection is established, and the sonarqube database is created.