Docker, Containers, Persistent Storage, and Production Deployment: Configuration, Design Patterns, and Trade-Offs

1. Production container design starts with state and trust

The fastest command is not automatically the safest operating model. Ask first: which state must survive; who can read secrets; which host/network boundary is trusted; how do we identify image content; how are logs retained; how does an operator roll forward or recover after a failed change?

2. docker run versus Docker Compose

3. A production-shaped local Compose contract

This example remains a lab: one SonarQube container and one PostgreSQL container. It deliberately keeps database credentials outside the committed YAML via variable interpolation. A real production secret manager is a separate boundary.

name: sq-container-lab
services:
  db:
    image: postgres:17.11
    environment:
      POSTGRES_DB: sonar
      POSTGRES_USER: sonar
      POSTGRES_PASSWORD: ${SQ_DB_PASSWORD}
    volumes:
      - pgdata:/var/lib/postgresql/data
    networks: [backend]

  sonarqube:
    image: sonarqube:26.9.0.129388-community
    depends_on: [db]
    environment:
      SONAR_JDBC_URL: jdbc:postgresql://db:5432/sonar
      SONAR_JDBC_USERNAME: sonar
      SONAR_JDBC_PASSWORD: ${SQ_DB_PASSWORD}
    ports:
      - "127.0.0.1:9000:9000"
    volumes:
      - data:/opt/sonarqube/data
      - extensions:/opt/sonarqube/extensions
      - logs:/opt/sonarqube/logs
    networks: [backend]

networks:
  backend:
    internal: false
volumes:
  pgdata:
  data:
  extensions:
  logs:

Use a local untracked environment file containing only fake lab credentials if you need interpolation. For production, integrate a supported orchestrator/secret store and restrict Docker daemon access. Never commit real DB passwords.

4. Named volumes versus bind mounts

Current SonarSource Docker preparation guidance specifically instructs operators to create Docker volumes for data, logs, and extensions and warns that bind mounts can prevent plugins from populating correctly. That is stronger than a generic “either works” Docker tutorial.

If an organization must use bind mounts, treat that as a deliberate compatibility/security design requiring current documentation and tested ownership/SELinux behavior—not a casual substitution.

5. Runtime secret injection versus baked configuration

A password in a Dockerfile becomes image history and can leak to registries/caches. A password committed in Compose becomes repository history. A literal -e PASSWORD=... command becomes shell history. The safer pattern is to keep immutable images free of environment-specific secrets and inject credentials at runtime from a controlled secret source.

6. Pinned version tag versus digest pinning

sonarqube:26.9.0.129388-community is readable and release-specific. A digest such as sha256:62930c7f510534bb2bf551ca69ad3ee6f8e12b4116d394597c64cefccbb3313b identifies resolved content more strictly. Many teams record both: the tag communicates intent and the digest proves artifact identity.

# Human-readable release selection
image: sonarqube:26.9.0.129388-community

# Stronger immutability after validation
# image: sonarqube@sha256:62930c7f510534bb2bf551ca69ad3ee6f8e12b4116d394597c64cefccbb3313b

Do not copy this authoring-time digest forever. Re-resolve and review the digest when deliberately moving to a new release.

7. Container user and filesystem ownership

The official current image runs as non-root sonarqube (UID 1000 in the published build). Named volumes usually reduce host-path friction. Bind-mounted paths must be writable by the effective container user and compatible with host security policy. Changing the container to root to “make permissions work” removes a safety boundary instead of fixing ownership.

8. Read-only root filesystem: advanced hardening needs writable scratch

Current Linux guidance shows a read-only-container pattern only when required writable paths are provided, including a writable /tmp because SonarQube now includes Elasticsearch 8.x. Treat read-only root filesystem design as an advanced hardening exercise: validate all required writable mounts/tmpfs paths and do not blindly add read_only: true.

9. Single-container lab versus production topology

flowchart TD
U[Users / CI scanners] --> RP[Reverse proxy / TLS
controlled ingress]
RP --> SQ[SonarQube container
private/internal port]
SQ --> DB[(Supported external DB
separate backup/HA)]
SQ --> V[(Named volumes
search/extensions/logs)]
OBS[Logs / metrics / alerts] --> SQ
SEC[Secret source] --> SQ
HOST[Hardened host
limits + capacity] --> SQ

Containerization does not make a single Community Build container highly available. Data Center Edition clustering is a separate commercial architecture and is not simulated by simply starting two identical Community Build containers against one database.

10. Decision table

Knowledge check

Official references and version notes

• SonarQube Community Build downloads — current Community Build release identity.
• Official SonarQube Docker image tags — current official image tags and digests.
• Prepare the Docker installation — pre-installation checks and named-volume guidance.
• Set up and start your container — docker run/Compose, JDBC environment variables, ports, and volume warnings.
• Linux pre-installation — embedded-search host limits and writable /tmp requirements.
• Configuration methods — preferred Docker environment-variable configuration model.
• System properties — current JDBC and web-server property names.
• Installing database — supported database versions and H2 non-production boundary.
• Updating Community Build — container recreation and persistent-state upgrade guidance.
• SonarQube official image overview — official image usage, host prerequisites, port and edition tags.