CodeOath
← All posts
Docker65 min total · 19 parts

Docker Fundamentals: Images, Containers, and Writing a Good Dockerfile

Contents — Part 15 of 19: Environment-Specific Configuration
  1. 1.Overview
  2. 2.What Problem Docker Actually Solves
  3. 3.Image vs. Container
  4. 4.The Docker Engine's Moving Parts
  5. 5.Images Are Made of Layers, and Layers Are Cached
  6. 6.Dockerfile Instructions, One by One
  7. 7.CMD vs. ENTRYPOINT: The Instruction Everyone Mixes Up
  8. 8.Multi-Stage Builds
  9. 9..dockerignore and the Build Context
  10. 10.Choosing a Base Image
  11. 11.Networking Basics
  12. 12.Volumes, Bind Mounts, and tmpfs
  13. 13.Docker Compose: Running More Than One Container Together
  14. 14.Health Checks and Restart Policies
  15. 15.Environment-Specific Configuration
  16. 16.Security Basics
  17. 17.Debugging a Running Container
  18. 18.Resource Limits
  19. 19.Common Mistakes Worth Remembering
Part 15 of 19 · ~1 min

Environment-Specific Configuration

The same image should generally run in dev, staging, and production — what differs is configuration, not the artifact itself (this is the same "promote one build artifact" principle covered in the CI/CD reference). The standard mechanism is environment variables injected at docker run/Compose time, not baked into the image:

docker run -e DATABASE_URL=postgres://prod-host/app -e LOG_LEVEL=warn myapp

services:
  web:
    image: myapp:1.4.2
    env_file: .env.production   # loaded at container start, not build time

Baking environment-specific values into the image with ENV in the Dockerfile means building a different image per environment — which reintroduces exactly the "am I testing what I'm shipping" problem that promoting one artifact through environments is meant to avoid (see CI/CD Pipelines Explained). Keep the image environment-agnostic; inject configuration at runtime.

← Previous
Health Checks and Restart Policies
Next →
Security Basics