Sonar data volume persistence and state in Docker with ECS

I’m looking for recommendations on how to run my Sonarqube instance in ECS without the use of an EBS volume. EBS volumes are locked to a specific AZ and are not easily mounted at runtime on newer EC2 instances that use NVME volumes ([aws/ebs] NVMe support · Issue #1104 · rexray/rexray · GitHub).

My configuration:

  • Running Developer edition of Sonarqube 8.9 LTS using the sonarqube:8.9-developer Docker image
  • Today I’m mounting a single EBS volume to /var/sonarqube. This is mounted at runtime using the rexray driver.
  • Path for Sonar Data, Logs, and Temp are being set with ENV variables to /var/sonarqube/data, /var/sonarqube/logs, and /var/sonarqube/temp respectively
  • My DB is a Postgres DB, which runs in RDS independently from the Sonarqube application service
  • My ECS service definition ensures only 1 instance of Sonarqube runs at any given time.
  • I do not have any 3rd party extensions and, if I did need to add them with how 8.9+ functions, I would probably do that by copying them directly into my Docker image where I wouldn’t need them to sit on a persistent storage volume.
  • I do not need to persist my logs volume since I can pipe that log data into CloudWatch logs.

Options considered:

  1. Use EFS (an NFS data store) for the sonardata volume instead of EBS. The benefit of this is that ECS supports mounting an EFS volume at runtime out of the box without an additional storage driver like rexray and so won’t have issues with NVME storage. EFS is also multi-AZ and so is not limited to EC2 instances in a single AZ. With that said, the hardware recommendations say not to use NFS storage: Hardware Recommendations | SonarQube Docs. The throughput and IOPS on my EBS volume, however, are significantly lower than the capabilities of EFS so I’m not sure how relevant this recommendation is these days.
  2. Does the sonar data volume need to be persisted if the database is in Postgres? I realize this is a question and not a solution, but if there is no data that needs to be persisted here then I could consider allowing this data volume to be recreated each time the service is restarted and I don’t need a persistent data volume.
  3. Other ideas?

Hi,

Maybe someone will come along with better input. This is in no way my area of expertise. But there is one point I can answer:

This is where your ES indices are stored. Dump this data with each restart and depending on your instance size, you may have very long restart times as you wait for the indices to be recreated. We did some work in the 8-series to speed this up with progressive availability - you no longer need to wait for everything to be re-indexed before you can start using your instance - but it’ll still be a pain.

 
HTH,
Ann