Update docker-compose.yml | Issue#1933

[KjellWolf]

User description

Making the DB volume persistent.
Adding options to use a .env file
Removing the DB Port mapping

Based on my Issue #1933

---

PR Type

Enhancement

---

Description

• Remove database port mapping for security

• Make database volume persistent with named volume

• Support environment variable configuration with defaults

• Improve database credentials security and flexibility

---

Diagram Walkthrough

flowchart LR
  A["docker-compose.yml"] -->|Remove port mapping| B["Port 3306 hidden"]
  A -->|Add volume mount| C["db-data:/var/lib/mysql"]
  A -->|Add env variables| D["MYSQL_DATABASE<br/>MYSQL_USER<br/>MYSQL_PASSWORD"]
  D -->|Support defaults| E[".env file or defaults"]

Loading

File Walkthrough

	Relevant files
Configuration changes	docker-compose.yml Persistent storage and environment variable configuration docker-compose.yml Removed port mapping (3306:3306) to prevent external database access Added named volume db-data for persistent database storage Replaced hardcoded credentials with environment variable references using ${VAR:-default} syntax Updated default password from changeme to changeMe! for better security +5/-5

---

[qodo-free-for-open-source-projects]

PR Compliance Guide 🔍

Below is a summary of compliance checks for this PR:

Security Compliance
⚪	Weak default credentials Description: Database credentials are exposed through environment variables with weak default values that may be used in production if .env file is not properly configured. docker-compose.yml [16-18] Referred Code MYSQL_DATABASE: "${MYSQL_DATABASE:-stevedb}" MYSQL_USER: "${MYSQL_USER:-steve}" MYSQL_PASSWORD: "${MYSQL_PASSWORD:-changeMe!}"
Ticket Compliance
🟡	🎫 #1933 🟢 Add volume mount for MariaDB data persistence Remove the port binding for MariaDB (port 3306) 🔴 Add Docker Image support as described in Issue Add a docker network for traffic from DB to the frontend
Codebase Duplication Compliance
⚪	Codebase context is not defined Follow the guide to enable codebase context checks.
Custom Compliance
🟢	Generic: Comprehensive Audit Trails Objective: To create a detailed and reliable record of critical system actions for security analysis and compliance. Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Meaningful Naming and Self-Documenting Code Objective: Ensure all identifiers clearly express their purpose and intent, making code self-documenting Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Robust Error Handling and Edge Case Management Objective: Ensure comprehensive error handling that provides meaningful context and graceful degradation Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Secure Error Handling Objective: To prevent the leakage of sensitive system information through error messages while providing sufficient detail for internal debugging. Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Secure Logging Practices Objective: To ensure logs are useful for debugging and auditing without exposing sensitive information like PII, PHI, or cardholder data. Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
🔴	Generic: Security-First Input Validation and Data Handling Objective: Ensure all data inputs are validated, sanitized, and handled securely to prevent vulnerabilities Status: Weak Default Password: The default password changeMe! is weak and predictable, violating secure data handling practices for database credentials. Referred Code MYSQL_PASSWORD: "${MYSQL_PASSWORD:-changeMe!}" volumes: Learn more about managing compliance generic rules or creating your own custom rules

Compliance status legend

🟢 - Fully Compliant
🟡 - Partial Compliant
🔴 - Not Compliant
⚪ - Requires Further Human Verification
🏷️ - Compliance label

[qodo-free-for-open-source-projects]

PR Code Suggestions ✨

Explore these optional code suggestions:

Category	Suggestion	Impact
Security	Enforce setting a secure database password Enforce setting the MYSQL_PASSWORD by making the environment variable mandatory. If the variable is not set, docker-compose will exit with an error message instead of using a weak default password. docker-compose.yml [18] -MYSQL_PASSWORD: "${MYSQL_PASSWORD:-changeMe!}" +MYSQL_PASSWORD: "${MYSQL_PASSWORD:?You must set a MYSQL_PASSWORD in your environment (e.g., in a .env file)}" Apply / Chat Suggestion importance[1-10]: 9 __ Why: The suggestion correctly identifies a security risk with the default password and proposes a robust solution to enforce that a password must be set, which significantly improves the security of the deployment.	High
More

[goekay]

hey there, thanks for the effort.

this means that the database will not be accessible from localhost (let's say from a dev machine), right? it would be a little bit counter-productive IMO.

[KjellWolf]

Maybe there should be a Prod and Dev Compose file? or just commented out?

Having unnessesary ports open for prod is dangerus. Sadly most people deploy without thinking.

[goekay]

hmm. to be frank, i never never considered this docker-compose (or any kubernetes-related additions) for prod. i think both of them are too context-dependent and should be tuned to the org's infra.

this docker-compose for me is just a developer convenience shortcut to start steve easily in 1 step.

[goekay]

for example, my definition/interpretation of prod would be some managed database by the cloud provider i am using, such that this mysql/mariadb in docker-compose is completely unnecessary. there are so many downsides IMO to run a database locally like this. but every org's prod choices, context and configuration is different. it is too nuanced to cover in this project.

[KjellWolf]

Well most people i know nowdays see docker and use docker. Its just easy. Like you mentioned. And most People simly prefer containerized applications over bare metal installs

Especially if its not explicit stated that its Dev only.

And IMO prod users should have the option for Docker too :D

And maybe consider then "keep it simple" for the majority who just see and use and make it complex(er) for those who use it for Dev.

[goekay]

And IMO prod users should have the option for Docker too :D

my suggestion was not to run the app on bare metal or without docker. i have nothing against docker. my argument was that the dockerization of the app and the interplay with other components on your platform might look different from what is prescribed in the docker-compose.

going back to your earlier argument, i guess we could have two docker-compose files: dev and prod. dev should be easy to use without modification. prod can be safer and more elaborate.