Closed johnbradley closed 1 year ago
@thompsonmj When you get a chance could you review this PR? Thanks.
How about adding export BACKEND_WORKERS=$((2*$(nproc)+1))
to the deployment notes just before docker-compose
? That should make it automatically adjust if/when we change the EC2 instance type.
Or just put that formula in the .env
?
How about adding
export BACKEND_WORKERS=$((2*$(nproc)+1))
to the deployment notes just beforedocker-compose
? That should make it automatically adjust if/when we change the EC2 instance type.
I don't think docker-compose would make use of this environment variable.
Or just put that formula in the .env?
I don't think the docker-compose .env file syntax supports bash interpolation like this.
Ah OK, good to know about the unsupported .env bash interpolation. I found this for the first approach though:
Your configuration options can contain environment variables. Compose uses the variable values from the shell environment in which docker compose is run. [source]
I tested it with export BACKEND_WORKERS=$((2*$(nproc)+1))
before composing with a simple dummy Dockerfile just to check.
In run.sh
, we could add ${BACKEND_WORKERS:=4}
to give a default value in the case that the environment variable is not set beforehand.
Adds support for a BACKEND_WORKERS environment variable to control the number of workers used by the backend container. This controls the number of gunicorn processes. A example.env file is provided to give a safe default value for BACKEND_WORKERS. I broke out the command into a shell script within the Docker container to read the environment variable.
Fixes #40