DEV Community

Cover image for Docker environment variables naming
Adriano Galello
Adriano Galello

Posted on • Originally published at gdi3d.github.io

Docker environment variables naming

When you start to build an application you will definitively want to use environment variables for sensitive values like passwords, or configurations.

These values should never be hardcoded since it's a security issue. It will also help you make your application easier to maintain.

Typically you will also have one configuration file per environment:
Development, Preproduction, and Production.

Take a look at the following docker-compose for our next unicorn app:

version: "3.9"
services:
  app_backend:
    image: killerapp:latest
    ports:
      - "8080:8000"
    environment:
      - DB_HOST=${DB_HOST}
      - DB_USER=${DB_USER}
      - DB_PASSWORD=${DB_PASSWORD}
      - DB_SCHEMA=${DB_SCHEMA}
Enter fullscreen mode Exit fullscreen mode

This looks about right, and you're probably familiar with this kind of configuration. But this presents a problem that could be potentially dangerous.

There's a chance that someone accidentally set the env vars for one environment into another one.

Imagine what can happen if you end up using the production values in your preproduction or development environment.

One best practice is to have different variables for your environments.

There are other ways to prevent these issues like having your environments in different servers, VPC's, accounts, etc.

In our example, the docker-compose.yml will look like this:

version: "3.9"
services:
  app_backend:
    image: killerapp:latest
    ports:
      - "8080:8000"
    environment:
      - DEV_DB_HOST=${DEV_DB_HOST}
      - DEV_DB_USER=${DEV_DB_USER}
      - DEV_DB_PASSWORD=${DEV_DB_PASSWORD}
      - DEV_DB_SCHEMA=${DEV_DB_SCHEMA}
      - PRE_DB_HOST=${PRE_DB_HOST}
      - PRE_DB_USER=${PRE_DB_USER}
      - PRE_DB_PASSWORD=${PRE_DB_PASSWORD}
      - PRE_DB_SCHEMA=${PRE_DB_SCHEMA}
      - PRO_DB_HOST=${PRO_DB_HOST}
      - PRO_DB_USER=${PRO_DB_USER}
      - PRO_DB_PASSWORD=${PRO_DB_PASSWORD}
      - PRO_DB_SCHEMA=${PRO_DB_SCHEMA}
Enter fullscreen mode Exit fullscreen mode

This way is much harder for a developer/DevOps to accidentally use the production credentials in another environment.

The takeaway is that if you should have an environment-sensitive variable naming approach to make them crystal clear. This way, anyone that it's not familiar with the app config will be less prone to make mistakes.

Discussion (0)