SonarQube Tips & Tricks on CloudSOE Images

A collection of practical advice for running the CloudSOE SonarQube image in production, on either cloud.

Back up the database

Your analysis history, issues, quality gates and users all live in PostgreSQL. A simple nightly dump:

sudo -u postgres pg_dump sonarqube | gzip > /home/$(whoami)/sonarqube-db-$(date +%F).sql.gz

Ship it off the instance (S3, Azure Blob, anywhere). Cloud-level snapshots (EBS on AWS, disk snapshots on Azure) are a good complement — they also capture the Elasticsearch index, which otherwise rebuilds itself from the database on a fresh install.

Use tokens, not passwords, in CI

Never put the admin password in a pipeline. Generate a token per CI system (My Account → Security → Generate Tokens) and pass it as sonar.token. Tokens can be revoked individually without touching the admin account.

sonar-scanner -Dsonar.host.url=http://<public-ip>:9000 -Dsonar.token=<ci-token>

Restrict port 9000 in your security group / NSG to your CI runners and your own IP range.

Keep things updated

• OS security updates come from Ubuntu’s repositories: sudo apt update && sudo apt upgrade on your own schedule.
• SonarQube itself is installed from the official zip at /opt/sonarqube — upgrades follow SonarSource’s documented upgrade path (new version, same database). For major moves, take a database dump first, and consider launching a fresh CloudSOE image and restoring rather than upgrading in place.

Performance quick wins

1. Give it memory first — 4 GB is the floor; analysis of large projects is much happier at 8 GB (t3.medium → t3.large on AWS, B2s → D2as_v4 on Azure). Then raise the process heaps as shown in the configuration guide.
2. Watch the logs that matter — web.log for UI slowness, ce.log for slow background analysis, es.log for search issues. All under /opt/sonarqube/logs/.
3. Prune generously — housekeeping settings under Administration → Housekeeping keep the database from growing without bound.

Troubleshooting first boot

If you can’t log in with the generated password a few minutes after launch:

systemctl status sonarqube-firstboot
journalctl -u sonarqube-firstboot --no-pager
tail -n 50 /opt/sonarqube/logs/sonar.log

The first-boot script waits for SonarQube to come up before it can replace the default password, so on a slow start the credentials file can exist briefly before the admin password actually matches it — give it a couple of minutes. The script is safe to re-run: its completion marker is only written on success, so a failed run retries on the next boot.

SonarQube won’t start after a config change

Nine times out of ten it’s a typo in sonar.properties or a heap larger than the instance’s RAM. Check in order:

sudo systemctl status sonar
tail -n 100 /opt/sonarqube/logs/sonar.log
tail -n 100 /opt/sonarqube/logs/es.log

The kernel tuning (vm.max_map_count etc.) is already applied by the image, so the classic Elasticsearch bootstrap failure shouldn’t appear — if it does, someone changed the sysctls.

The MOTD shows the wrong IP

The login banner captures the public IP at first boot. If you later attach a new Elastic IP / public IP, the banner (and the WEB_URL line in the credentials file) will be stale — the server itself is unaffected. On Azure, use a static public IP so the address survives stop/start; see the configuration guide for fronting it with a proper domain and HTTPS.