From Frustrated to Successful: My Experience Deploying SonarQube in Azure

SonarQube is a popular open-source platform for continuous code inspection that helps developers identify and fix coding issues, security vulnerabilities, and other bugs in their codebase. As someone who has worked on multiple software projects, I can attest to the importance of having a tool like SonarQube in your toolkit. It saves time and prevents headaches by catching issues early on rather than at the end of a project. Recently, I struggled with deploying the latest version of SonarQube on Azure App Service, so I created the repository mhdbouk/azure-sonarqube (github.com) to document my process and help others avoid the same pitfalls. In this blog post, I’ll share my experience with deploying SonarQube on Azure App Service and provide the repository for anyone who may find it useful.

The issue with latest version in App Service

I encountered a frustrating issue when attempting to deploy SonarQube using a Bicep file that included an Azure App Service, App Service plan. When trying to run the Docker image inside the Azure web app, I received an exception stating that the virtual memory allocated to the container was too low and needed to be increased to 262144. However, this option cannot be updated in Azure App Service, so I had to find an alternative solution.

max virtual memory areas vm.max_map_count [65530] is too low, increase to at least [262144]

I spent hours hitting my head against the keyboard, frantically searching the web for a solution. One option I considered was using an older version of SonarQube, as versions 7.8 and above require the vm.max_map_count to be set to 262144. However, I was not willing to downgrade to a version of SonarQube that was 4 years old in order to fix the issue. After crying out loud in frustration, I finally found a solution: adding the following app setting SONAR_SEARCH_JAVAADDITIONALOPTS with a value of -Dnode.store.allow_mmap=false. This allowed me to successfully run the latest version of SonarQube without any issues, and I was extremely relieved and happy to have found a solution.

SQL Server Support

By default, SonarQube creates an in-memory database that is useful for testing purposes only. In order to run SonarQube in a production environment, it is necessary to configure it to use a persistent database such as SQL Server. In this case, I added the needed Bicep resources and the necessary configuration to run SonarQube using SQL Server, which was also created and deployed using the Bicep file.

In order to configure SonarQube to use a persistent database, you added the following app settings to the siteConfig block in the Bicep file:

...
siteConfig {
  appSettings: [
    {
      name: 'SONARQUBE_JDBC_URL'
      value: 'jdbc:sqlserver://${sqlserver.outputs.fullyQualifiedDomainName}:1433;database=${sqlDatabaseName};encrypt=true;trustServerCertificate=false;hostNameInCertificate=*.database.windows.net;loginTimeout=30;'
    }
    {
      name: 'SONARQUBE_JDBC_USERNAME'
      value: adminSqlUsername
    }
    {
      name: 'SONARQUBE_JDBC_PASSWORD'
      value: adminSqlPassword
    }
  ]
}
...

Bicep Modules

Bicep modules are self-contained blocks of Bicep code that can be reused and imported into other Bicep files, making it easier to manage and maintain complex deployments. I used the following Bicep modules in this repository:

• linux-plan.bicep: This module creates an Azure App Service Plan with a Linux operating system. It includes the necessary output for the web app resource.
• sqlserver.bicep: This module creates an Azure SQL Server and an Azure SQL database. It includes the necessary output for the web app resource, including the full qualified domain name of the SQL server.

To use a Bicep module, first you create a new bicep file, add the resources and the parameters needed, and then simply import it using the module function and specify the path to the module file. For example:

// sqlserver.bicep
param location string = resourceGroup().location
...

resource sqlServer 'Microsoft.Sql/servers@2022-05-01-preview' = {
  location: location
  name: sqlServerName
  tags: {
    displayName: 'Sql Server'
  }
  properties: {
    administratorLogin: adminSqlUsername
    administratorLoginPassword: adminSqlPassword
    version: '12.0'
    publicNetworkAccess: 'Enabled'
  }
}


output fullyQualifiedDomainName string = sqlServer.properties.fullyQualifiedDomainName


// main.bicep
module sqlserver 'sqlserver.bicep' = {
  ...
}

// Use the module output
fqdn: sqlserver.outputs.fullyQualifiedDomainName

Conclusion

In this blog post, we shared our experience with deploying the latest version of SonarQube on Azure App Service using Bicep and Docker. We encountered an issue during the deployment process, but were able to find a solution and successfully run the latest version of SonarQube.

We also explained how we used Bicep modules to organize and deploy the necessary resources. We then configured SonarQube to use the SQL Server by adding the necessary configuration to the Bicep file.

Overall, using Bicep and Docker made it easy to deploy and configure SonarQube on Azure. And now, with the provided bicep file, you can easily create a new instance of SonarQube with just a few clicks. Happy coding!