Environment variables and config

The core idea

The same image should run in development, staging and production. What changes between them (database address, log level, feature limits) is configuration, and the standard way to hand it to a container is environment variables. Build once, configure at run time.

Setting variables

$ docker run --rm -e GREETING=hi alpine env
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
GREETING=hi
HOME=/root
...

Four ways in, from least to most specific:

Run-time values override image defaults:

$ docker run --rm notes-api node -e 'console.log(process.env.NODE_ENV)'
production
$ docker run --rm -e NODE_ENV=development notes-api node -e 'console.log(process.env.NODE_ENV)'
development

Making the notes API configurable

The notes API now reads two settings, with defaults, and refuses to start if one is invalid:

function intFromEnv(name: string, fallback: number) {
const raw = process.env[name];
if (raw === undefined || raw === "") return fallback;
const value = Number(raw);
if (!Number.isInteger(value) || value <= 0) {
  console.error(`config error: ${name} must be a positive integer, got "${raw}"`);
  process.exit(1);
}
return value;
}

const port = intFromEnv("PORT", 3000);
const maxNoteLength = intFromEnv("MAX_NOTE_LENGTH", 280);

$ docker run --name bad -e MAX_NOTE_LENGTH=lots notes-api
config error: MAX_NOTE_LENGTH must be a positive integer, got "lots"
$ echo $?
1

Failing fast matters more in containers than anywhere else: a restart policy or orchestrator will notice the exit immediately, while a service that starts with bad config and limps along can go unnoticed for days.

Where environment variables leak

Environment variables are convenient, not secret. Anyone who can talk to the Docker daemon can read them:

$ docker run -d --name envy --env-file app.env alpine sleep 100
$ docker inspect -f '{{json .Config.Env}}' envy
["DB_HOST=db","DB_PASSWORD=s3cret","PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"]

They also end up in crash reports, debug pages and child processes. And ENV or ARG with a secret in a Dockerfile is worse: it's saved in the image itself. For real secrets, use mounted secret files and build secrets (07.02 Secrets without leaks).

Recap

Interview questions