Up to 10 M LOC

This page describes the architecture of a SonarQube Server instance that will support up to 10 million lines of code under normal usage patterns in a non-high availability setup.

Overview

This reference architecture covers the following components:

  • A virtual machine host with SonarQube Server (Developer or Enterprise Edition) installed and an nginx HTTPS proxy.

  • PostgreSQL database on a dedicated host.

  • Analysis integrated with GitHub Actions.

  • Authentication through GitHub.com.

  • Monitoring with Prometheus.

  • Outbound email notifications using an SMTP relay.

Architecture schema of a SonarQube Server instance with a PostgreSQL database, connected through an Nginx proxy with GitHub platform, SonarQube for IDE, Prometheus monitoring system. Data flow or access type are shown. GitHub Actions is used as CI tool.

This architecture favors the use of open-source components when available. These may be substituted with other similarly capable components, and it is recommended that organizations use components that they are comfortable supporting.

SonarQube Server Host

The SonarQube Server Host will have the SonarQube Server software installed as well as nginx acting as an HTTPS proxy.

Host specification

  • VM configuration:

    • 4 vCPU

    • 8 GB RAM

    • 50GB SSD Local Storage

  • AWS EC2: c5d.large

  • Azure VM: F4s_v2

  • GCE: c3-highcpu-4

Networking

By source/destination:

  • SonarQube Server host:

    • Direction: Outbound

    • Port: 5432

    • Purpose: Database

  • SonarQube Server host:

    • Direction: Outbound

    • Port (Protocol): 25 (SMTP)

    • Purpose: Email notifications

  • Internal network (user desktops):

    • Direction: Inbound

    • Port (Protocol): 443 (HTTPS)

    • Purpose: Inbound web and API traffic

  • CI platform (GitHub Runners):

    • Direction: Inbound

    • Port (Protocol): 443 (HTTPS)

    • Purpose: Analysis reports

  • DevOps platform (GitHub.com):

    • Direction: Inbound

    • Port (Protocol): 443 (HTTPS)

    • Purpose: Pull Request reports

Software

  • OS - Ubuntu Server (or other Linux distribution)

  • OpenJDK 17

  • SonarQube Server’s Developer or Enterprise Edition

  • nginx

    • Configured as a reverse proxy between incoming traffic and SonarQube Server port 9000.

    • Secured with SSL. Use of self-signed SSL certificates will require installation of the certificate on all CI build agents, and developer desktops using SonarQube for IDE.

    • May be substituted with other reverse proxy (ex. haproxy) or a solution from a cloud provider, such as an AWS Application Load Balancer (ALB).

Database

This architecture utilizes a dedicated PostgreSQL database installed on a separate host.

Host specification

  • VM Configuration:

    • 2vCPU

    • 8 GB RAM

    • 30 GB table space

  • AWS RDS:

    • db.t3.large

    • 30 GB table space

  • Azure SQL:

    • B2ms

    • 30 GB table space

  • Google Cloud SQL:

    • 2 vCPU

    • 8 GB memory

    • 30 GB table space

Database requirements can vary widely based on the usage patterns of each SonarQube Server installation. Therefore, it is important to monitor and adjust database resources as needed.

PostgreSQL may be substituted with other supported database platforms.

DevOps/CI platform

Automated analysis of source code is enabled through the installation of the various SonarScanners into continuous integration pipelines. When using GitHub Actions, scanners are initiated through the repository’s workflow YAML file(s).

Upon analysis completion, SonarQube Server submits reports back to pull requests to integrate with code review processes. This functionality is enabled in GitHub.com using a GitHub App.

GitHub.com may be substituted with other supported DevOps and/or CI platforms without changes to other components in this architecture.

Authentication

It is recommended that authentication and authorization be handled through an external identity provider. The architecture utilizes the GitHub App to authorize users and synchronize access to SonarQube Server projects.

Other external identity providers such as SAML may be substituted. Features such as group and permission synchronization are not available for all authentication methods.

Monitoring

SonarQube Server exposes endpoints that are easy to monitor using Prometheus or other monitoring solutions. In addition to the overall system health of both the SonarQube Server host and database, it is recommended to monitor SonarQube Server’s Compute Engine performance statistics to ensure incoming analyses are being promptly processed.

Email notifications

Users can be notified of new issues and events via email. SonarQube Server will deliver these notifications through an SMTP mail relay. The volume of emails is low, dependent on the number of users subscribed, and a dedicated SMTP server is typically not required.

Resiliency

As a single-host installation, this architecture relies on robust monitoring, automated backups of the database, and a rapid recovery process to maximize resiliency. If high availability is critical, SonarQube Server Data Center Edition is recommended.

Scalability

This architecture is designed to support typical production usage for up to 10 million lines of code. Beyond this, it is recommended that organizations use SonarQube Server Enterprise Edition or Data Center Edition to support high-volume workloads.

The following use cases are considered outside of "normal usage" and may require additional capacity:

High-frequency analysis

Normal usage assumes a daily scan of main branches and analysis of several pull requests. Scanning code more frequently may require an increase in the number of Compute Engine workers (using SonarQube Server Enterprise Edition) as well as additional memory and CPU resources allocated to SonarQube Server’s Compute Engine process. Monitoring of the Compute Engine process will ensure that your installation can keep up with demand.

Large repositories

This architecture assumes analyzed repositories average 50,000 lines of code. If your organization is scanning a majority of very large repositories (where the repositories average 500,000 lines of code or more), additional memory and CPU resources may be required for SonarQube Server’s Compute Engine process.

Heavy API integration

SonarQube Server exposes a REST-based API for reporting and automation of administration tasks. This architecture assumes occasional use of this API. Heavy use of this API may require the allocation of additional memory and CPU resources to SonarQube Server’s Web process.

Third-party plugins

This architecture assumes that no third-party plugins are in use. As these extensions are developed by open-source developers, their impact on the performance of a SonarQube Server instance varies based on the function being performed and the quality of the implementation. It is recommended that the use of third-party plugins is carefully considered and monitored for performance throughout the life of your SonarQube Server implementation.

Related pages

PreviousReference architecturesNextUp to 50 M LOC

Last updated

Was this helpful?