如何在AWS Elastic Beanstalk稳定配置SonarQube 7.1？实例回收环境丢失

I've tested several ways to deploy SonarQube on AWS—all get the service up and running, but they share a critical stability flaw: every time Elastic Beanstalk recycles an instance, SonarQube's custom configurations (especially plugins and manual settings) disappear. Let's walk through the tried approaches first, then jump to actionable fixes:

Deployment Attempts & Their Issues #

Attempt 1: Bitnami AMI on EC2 #

• Super easy to spin up using ami-0f9cf81913a6dce27
• Downside: Doesn't take advantage of Elastic Beanstalk's automated management tools, which is a must for our ops workflow

Attempt 2: Single Docker Instance on EB #

Used this Dockerrun.aws.json config:

{ 
  "AWSEBDockerrunVersion": "1", 
  "Image": { "Name": "sonarqube:7.1" }, 
  "Ports": [{ "ContainerPort": "9000" }] 
}

• Automatically provisions a MySQL 5.x RDS instance (db name ebdb) for scan data, with SonarQube using its built-in Elasticsearch for search functionality
• I manually set up JDBC env vars, security settings, installed SonarJava, Groovy, SonarJS plugins, and created scan users
• Critical Issue: When EB rebuilds instances due to health checks, security configs (users/passwords) stick around in RDS, but manually installed plugins get wiped—breaking code scans. Plus, single Docker setups offer almost no customization room.

Attempt 3: Multi-Container Docker on EB #

• Pros: Way more flexible, supports env var passing, custom MySQL setup, etc.
• Issue: Even after ensuring instances have >2GB RAM (required for Elasticsearch), the environment failed to start properly. I plan to troubleshoot this approach later.

Attempt 4: Terraform + EB + Bitnami AMI #

Core main.tf config:

resource "aws_elastic_beanstalk_application" "sonarqube" { 
  name = "SonarQube" 
  description = "SonarQube for nano-services" 
} 

resource "aws_elastic_beanstalk_environment" "nonprod" { 
  name = "${var.application-name}" 
  application = "${aws_elastic_beanstalk_application.sonarqube.name}" 
  solution_stack_name = "64bit Amazon Linux 2018.03 v2.10.0 running Docker 17.12.1-ce" 
  wait_for_ready_timeout = "30m" 

  setting { 
    namespace = "aws:autoscaling:updatepolicy:rollingupdate" 
    name = "Timeout" 
    value = "PT1H" 
  } 
  # Remaining settings omitted for brevity
}

Initially included the Bitnami AMI setting:

setting { 
  namespace = "aws:autoscaling:launchconfiguration" 
  name = "imageId" 
  value = "ami-0f9cf81913a6dce27" 
}

• Issue: EC2 instances took too long to start, triggering EB's gray status (even though SonarQube was running). Fixed by commenting this setting and manually updating the image ID later.
• Final setup used local MySQL/Elasticsearch, with most plugins pre-installed (only Groovy needed manual addition)
• Persistent Problem: Custom configurations still vanish when instances are recycled.

Solutions to Fix Configuration Loss #

1. Persist Critical Directories with EFS #

SonarQube's plugins and configs are stored locally by default—use Elastic File System (EFS) to make these persistent:

• Create and mount an EFS volume to your EB environment
• Map SonarQube's extensions/plugins and conf directories to the EFS mount point
  • For Docker deployments: Update Dockerrun.aws.json to include volume mounts
  • For AMI deployments: Add a user data script to mount EFS and sync these directories on instance startup

2. Build a Custom Docker Image with Pre-Installed Plugins #

Skip manual plugin installs by building your own SonarQube image:

FROM sonarqube:7.1
RUN sonar-plugin-installer install SonarJava Groovy SonarJS

Push this image to AWS ECR, then reference it in your EB Dockerrun config. Instances will now spin up with all required plugins pre-loaded.

3. Automate All Configs with Terraform #

Use Terraform to eliminate manual setup steps:

• Pass SonarQube env vars (JDBC settings, security configs) via EB's aws:elasticbeanstalk:application:environment namespace
• Add a user_data script to your launch configuration that auto-installs missing plugins and creates scan users on instance startup
• Ensure all dynamic data is stored in RDS (not local instance storage) for persistence

4. Tune EB Health Checks #

Fix the slow-start gray status issue:

• Extend health check timeouts via the aws:elasticbeanstalk:healthreporting:system namespace in your Terraform config
• Use SonarQube's official health endpoint (/api/system/health) as EB's health check target, so EB correctly identifies when the instance is ready

内容的提问来源于stack exchange，提问作者Tim