fix: fill creds in compose from env #9714
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -52,9 +52,9 @@ x-app-env: &app-env | |
| CORS_ALLOWED_ORIGINS: ${CORS_ALLOWED_ORIGINS} | ||
| GUNICORN_WORKERS: 1 | ||
| USE_MINIO: ${USE_MINIO:-1} | ||
| DATABASE_URL: ${DATABASE_URL:-postgresql://${POSTGRES_USER:-plane}:${POSTGRES_PASSWORD:-plane}@${PGHOST:-plane-db}:${POSTGRES_PORT:-5432}/${POSTGRES_DB:-plane}} | ||
|
Contributor
There was a problem hiding this comment. 🔒 Security & Privacy | 🟠 Major | 🏗️ Heavy lift Require authenticated TLS for remote database and broker connections. When 📍 Affects 1 file
🤖 Prompt for AI Agents |
||
| SECRET_KEY: ${SECRET_KEY} | ||
| AMQP_URL: ${AMQP_URL:-amqp://${RABBITMQ_USER:-plane}:${RABBITMQ_PASSWORD:-plane}@${RABBITMQ_HOST:-plane-mq}:${RABBITMQ_PORT:-5672}/${RABBITMQ_VHOST:-plane}} | ||
|
Comment on lines
+55
to
+57
Contributor
There was a problem hiding this comment. 🩺 Stability & Availability | 🟠 Major | ⚡ Quick win 🔎 Supported by static analysis🏁 Script executed: #!/bin/bash
set -euo pipefail
env_file=$(mktemp)
config_file=$(mktemp)
trap 'rm -f "$env_file" "$config_file"' EXIT
cat >"$env_file" <<'EOF'
DATABASE_URL=
POSTGRES_USER=verify_user
POSTGRES_PASSWORD=verify_password
PGHOST=plane-db
POSTGRES_DB=plane
POSTGRES_PORT=15432
AMQP_URL=
RABBITMQ_USER=verify_user
RABBITMQ_PASSWORD=verify_password
RABBITMQ_HOST=plane-mq
RABBITMQ_PORT=15672
RABBITMQ_VHOST=plane
EOF
docker compose \
-f deployments/cli/community/docker-compose.yml \
--env-file "$env_file" config --format json >"$config_file"
jq '{
database_url: .services.api.environment.DATABASE_URL,
amqp_url: .services.api.environment.AMQP_URL,
postgres_command: .services["plane-db"].command,
postgres_environment: .services["plane-db"].environment,
rabbitmq_command: .services["plane-mq"].command,
rabbitmq_environment: .services["plane-mq"].environment
}' "$config_file"Repository: makeplane/plane Length of output: 198 🏁 Script executed: set -euo pipefail
printf '%s\n' '--- repository conventions ---'
find /tmp/coderabbit-repo-knowledge/makeplane-plane-9ea351f0 -mindepth 2 -maxdepth 2 -type f -name '*.md' -print
printf '%s\n' '--- compose file ---'
cat -n deployments/cli/community/docker-compose.yml | sed -n '1,130p'
printf '%s\n' '--- related environment files ---'
fd -i 'variables\.env|plane\.env' deployments/cli/community -x sh -c 'echo "--- $1"; cat -n "$1"' shRepository: makeplane/plane Length of output: 10084 🏁 Script executed: set -euo pipefail
cat -n deployments/cli/community/docker-compose.yml | sed -n '124,280p'Repository: makeplane/plane Length of output: 4162 🌐 Web query:
💡 Result: For both the official PostgreSQL and RabbitMQ Docker images, there is no single "official" environment variable (like POSTGRES_PORT or RABBITMQ_NODE_PORT) that acts as a direct, simple toggle to change the service's internal listening port in the way users often expect [1][2][3]. PostgreSQL Docker Image: The official PostgreSQL Docker image does not support a dedicated environment variable named POSTGRES_PORT to configure the server port [1][3]. While some internal entrypoint scripts respect the standard PostgreSQL PGPORT environment variable for temporary server operations during initialization [4], changing the primary listening port should be done by passing configuration arguments directly to the container command [1][5]. You can do this by appending arguments to the docker run command, which are passed to the postgres executable [1][5]: docker run -d postgres -c port=5433 Alternatively, you can provide a custom configuration file by mounting it into the container and specifying it with the -c config_file=... argument [1][5]. RabbitMQ Docker Image: The official RabbitMQ Docker image does not use a specific environment variable to change the main service port [2]. While RABBITMQ_NODE_PORT is an environment variable recognized by the underlying RabbitMQ server in some contexts, relying on it in the Docker image is discouraged and often ineffective because the official image entrypoint script generates configuration files that may override such settings [6][7][8][2]. The recommended approach is to provide a custom configuration file (e.g., rabbitmq.conf) and mount it into the container at /etc/rabbitmq/rabbitmq.conf to define your desired port settings explicitly [6][8][2]. In general practice for both images, the most robust way to handle port changes is to map the container's internal port to a different port on the host machine using the standard Docker -p flag (e.g., -p 8080:5432) rather than attempting to change the configuration inside the container itself [9][10]. Citations:
Align client ports with bundled service ports. If 🤖 Prompt for AI Agents |
||
| API_KEY_RATE_LIMIT: ${API_KEY_RATE_LIMIT:-60/minute} | ||
| MINIO_ENDPOINT_SSL: ${MINIO_ENDPOINT_SSL:-0} | ||
| LIVE_SERVER_SECRET_KEY: ${LIVE_SERVER_SECRET_KEY} | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🩺 Stability & Availability | 🟠 Major | 🏗️ Heavy lift
🔎 Supported by static analysis
🏁 Script executed:
Repository: makeplane/plane
Length of output: 198
🏁 Script executed:
Repository: makeplane/plane
Length of output: 23625
🏁 Script executed:
Repository: makeplane/plane
Length of output: 46063
🌐 Web query:
official Docker postgres image POSTGRES_PASSWORD existing database volume initialization environment variables only first initialization💡 Result:
In the official Docker PostgreSQL image, the environment variable POSTGRES_PASSWORD and any initialization scripts located in the /docker-entrypoint-initdb.d/ directory are only processed during the container's first initialization [1][2][3]. This behavior is designed to prevent the overwriting or corruption of existing databases [1]. The container's entrypoint script checks whether the PostgreSQL data directory (by default /var/lib/postgresql/data) is empty [1][2]. Key points regarding this initialization process: 1. First Initialization: If the data directory is empty, the container executes the initdb process to create a new database cluster [1][2]. It then applies the POSTGRES_PASSWORD environment variable to set the superuser password and subsequently executes any *.sql, *.sql.gz, or executable *.sh scripts found in /docker-entrypoint-initdb.d/ [2][3]. 2. Existing Data: If the data directory is not empty—such as when a volume containing existing database files is mounted—the container skips both the initialization process and the execution of any scripts in /docker-entrypoint-initdb.d/ [1][2]. In this state, PostgreSQL starts using the existing configuration and credentials previously defined in that data volume [1]. 3. Managing Credentials: If you reuse an existing volume, the POSTGRES_PASSWORD environment variable will not override the password already set within that database [1]. To change the password for an existing database, you must either connect to the database and use SQL commands (e.g., ALTER USER postgres WITH PASSWORD 'newpassword';) or remove the volume to trigger a fresh initialization [1]. If you require scripts to run every time the container starts, regardless of whether the volume contains existing data, you must implement a custom entrypoint script or extend the official image to handle such logic, as the standard behavior is strictly limited to the initial setup [2][4].
Citations:
Preserve PostgreSQL credentials for existing volumes.
plane-dbmountspgdata, and thepostgres:15.7-alpineimage appliesPOSTGRES_USERandPOSTGRES_PASSWORDonly during initial database creation. Changing either variable updates the fallbackDATABASE_URLused byapi,worker,beat-worker, andmigrator, but not the credentials stored inpgdata. Those services can then fail authentication. Add a credential-rotation procedure or document that these changes require a fresh database volume.🤖 Prompt for AI Agents