DEV Community

Cover image for Docker environment variables naming
Adriano Galello
Adriano Galello

Posted on • Originally published at gdi3d.github.io

1 1

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.

Sentry image

Hands-on debugging session: instrument, monitor, and fix

Join Lazar for a hands-on session where you’ll build it, break it, debug it, and fix it. You’ll set up Sentry, track errors, use Session Replay and Tracing, and leverage some good ol’ AI to find and fix issues fast.

RSVP here →

Top comments (0)

Billboard image

The Next Generation Developer Platform

Coherence is the first Platform-as-a-Service you can control. Unlike "black-box" platforms that are opinionated about the infra you can deploy, Coherence is powered by CNC, the open-source IaC framework, which offers limitless customization.

Learn more

👋 Kindness is contagious

Please leave a ❤️ or a friendly comment on this post if you found it helpful!

Okay