Docker Tip #93: Remove the env_file Property from Postgres and Redis
You can almost cut your app's Docker Compose recreate containers time in half by avoiding needless recreates on .env changes.
Prefer video? Here’s a recorded version of this tip on YouTube.
It’s very common to have something like this defined in your
docker-compose.yml file:
services:
myapp:
env_file:
- ".env"
This way you can have your environment variables defined in a single .env file.
It’s also very common to re-use that .env file in other containers like this:
services:
postgres:
env_file:
- ".env"
redis:
env_file:
- ".env"
This is especially true with Postgres where you need to define at least a
POSTGRES_USER and POSTGRES_PASSWORD for the container to start. It makes
sense to drop those in a .env file so you may have blindly copy / pasted your
env_file reference to all of your containers because “why not?” (I know I did
for a while).
In Docker Tip #90 I went
over how docker compose up works around recreating containers based on what
changes which does include .env values.
If you used the above set up then every time you changed one of your app’s
.env variables (such as an unrelated Stripe API key) then Postgres and Redis
will get recreated!
You can avoid that by removing env_file from both services or more generally
any service where you don’t want to needlessly recreate them on all .env var
changes.
You can securely insert your POSTGRES_USER and POSTGRES_PASSWORD variables
into Postgres like this:
services:
postgres:
environment:
POSTGRES_USER: "${POSTGRES_USER}"
POSTGRES_PASSWORD: "${POSTGRES_PASSWORD}"
# POSTGRES_DB: "${POSTGRES_DB}"
It will read these values from your .env file thanks to Docker Compose
supporting variable interpolation, which I covered in my DockerCon 21
talk btw.
All of my example Docker web
apps use this
pattern. It dropped my docker compose up -d time from ~5.5 seconds down to
about 3.5 seconds for .env changes.