We deploy SonarQube as a StatefulSet (the default option) and every re-deployment leads to a downtime of the service since the pod is first terminated before a new one is spun up. We tried to change to Deployment (a deprecated option) but the only deployment strategy is Recreate, no rolling update possible. This effectively means we cannot do any redeployments of SonarQube without introducing a downtime of the service. Is there anything we can do to have zero-downtime deployments of SonarQube? Today it is a standard practice, is there any reason why SonarQube is not designed to fully support it?
Note that we are not using PVCs, there is no statefulness in our deployments.
SonarQube does require some downtime during upgrades to perform database migrations and refresh indexing. This applies across all editions and deployment methods.
However, it’s notable that we’ve significantly reduced this downtime compared to earlier versions. Database migrations are faster, and only the minimum necessary indexing is completed before SonarQube starts accepting analysis reports. Additionally, processing analysis reports is now prioritized over background indexing tasks.
Thanks @Colin. I was benchmarking how long it takes to redeploy SonarQube (since pod restart until accepting network traffic) and it is 2-3min when checking /api/system/status endpoint from within the EKS cluster. When checking externally via a load balancer, it is 3+min because of AWS ALB overhead.
3min downtime is unfortunately a no-go for us. We are left with doing redeployments over the weekends which defies purpose of running a containerized application in EKS.
Is there any other option for us? Is rolling update technically impossible for SonarQube?
The longer answer is that when I first read your post, I assumed you were referring to upgrading SonarQube (in terms of version). Re-reading your post, I think you’re talking about something else (redeployment).
Regardless, you can still only run a single node of SonarQube Enterprise Edition against your SonarQube instance at a time. Therefore, some downtime is required.
We are facing the same challenge. I understand that the license only allows one running instance but couldn’t this requirement be changed to allow at least a rolling restart?
I can confirm nonetheless the findings, SonarQube cannot be upgraded without a downtime, even if its a minor update without db migration.
We would love to make SonarQube more cloud-native in that regard, nonetheless there are few technical challenges that makes this to not be top priority.
huge thanks again for participating in the community.