Start Free
Latest | Server installation and setup | Reference architectures | Up to 50 M LOC

Reference architecture for Enterprise Edition (up to 50 M LOC)

On this page

Overview SonarQube Server Host Database DevOps platform CI/CD platform Authentication Monitoring Email notifications Resiliency Scalability Related pages

This architecture describes the setup of a SonarQube Server Enterprise Editon instance that will support up to 50 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 Enterprise Edition installed and an nginx HTTPS proxy
  • PostgreSQL database on a dedicated host
  • Analysis integrated with Jenkins CI
  • Pull request reporting and authentication through GitHub Enterprise
  • Monitoring with Prometheus
  • Outbound email notifications using an SMTP relay

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: 
    • 8 vCPU
    • 16 GB RAM
    • 50GB SSD Local Storage
  • AWS EC2: c5d.2xlarge
  • Azure VM: F8s_v2
  •  GCE: c3-highcpu-8
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 (Jenkins):
    • Direction: Inbound
    • Port (Protocol): 443 (HTTPS)
    • Purpose: Analysis reports
  • DevOps platform (GitHub Enterprise):
    • Direction: Inbound
    • Port (Protocol): 443 (HTTPS)
    • Purpose: Pull Request reports
Software
  • OS - Ubuntu Server (or other Linux distribution)
  • OpenJDK 17
  • SonarQube Server 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:
    • 4vCPU
    • 16 GB RAM
    • 150 GB table space
  • AWS RDS:
    • db.t3.xlarge
    • 150 GB table space
  • Azure SQL:
    • B4ms
    • 150 GB table space
  • Google Cloud SQL:
    • 4 vCPU
    • 16 GB memory
    • 150 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 platform

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

GitHub Enterprise may be substituted with other supported DevOps platforms without changes to other components in this architecture.

CI/CD platform

Automated analysis of source code is enabled through the installation of the various SonarScanners into continuous integration pipelines. When using Jenkins, the SonarQube extension for Jenkins manages the installation of the scanners and provides functionality to ease the integration of Sonar analysis into build pipelines. 

Other CI platforms may be used 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 50 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 non-sponsored 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.

Was this page helpful?

© 2008-2024 SonarSource SA. All rights reserved. SONAR, SONARSOURCE, SONARQUBE, and CLEAN AS YOU CODE are trademarks of SonarSource SA.

Creative Commons License