Docker has been a standard tool in development workflows for a decade. Most developers understand the basics (containers, images, Dockerfile), but there is a set of more advanced usage patterns that separate efficient Docker users from those who fight it. Here is what the basics tutorials typically miss.
Image Building Best Practices
Layer caching: Docker builds images in layers, one per Dockerfile instruction. Each layer is cached unless the layer itself or any preceding layer changes. The practical implication: put instructions that change rarely (installing system packages) before instructions that change often (copying application code). The typical mistake: `COPY . .` early in the Dockerfile means any code change invalidates all subsequent layers. The correct pattern: copy dependency manifests first, install dependencies, then copy code. Example for a Node.js project: `COPY package*.json ./; RUN npm ci; COPY . .` — this way, the `npm ci` layer is cached until package.json changes. Multi-stage builds: a powerful feature that most developers underuse. Use separate build stages to create the compiled output, then copy only what you need into a lean production image. Example for a Go binary: `FROM golang:1.22 AS builder; WORKDIR /app; COPY . .; RUN go build -o app; FROM alpine:3.19; COPY –from=builder /app/app /app; CMD [“/app”]`. The production image is Alpine (5MB) not Go (800MB). The .dockerignore file: functions identically to .gitignore — prevents unnecessary files from being included in the build context (node_modules, .git, test files, local .env). Without it, large directories are sent to the Docker daemon on every build. Non-root users: run application processes as a non-root user inside containers. `RUN adduser -D appuser; USER appuser`. Root inside a container can still cause privilege escalation issues if the container is compromised.
docker-compose for Development
docker-compose (now `docker compose` as a Docker CLI plugin) is the primary tool for running multi-container local development environments. The `depends_on` pitfall: `depends_on` only waits for the container to start, not for the service inside it to be ready. A database container that starts quickly but takes 5 seconds for the database process to accept connections will cause the dependent application to fail on startup. Solutions: use `healthcheck` in docker-compose.yml to define when the service is actually ready; use `wait-for-it.sh` or `dockerize` inside the application container to poll until the dependency is available. Environment variables: use a `.env` file for local development variables and reference them in docker-compose.yml with `${VARIABLE_NAME}`. Never commit actual secrets in docker-compose.yml — reference environment variables or Docker secrets. Volume mounts for development: mounting the source code directory into the container enables hot reloading without rebuilding the image. `volumes: – .:/app` in docker-compose.yml. Combine with a tool like nodemon, Air (Go), or the development mode of your framework. Named volumes vs bind mounts: bind mounts (the above) link to a host path; named volumes (`volumes: db_data:` at the top, `- db_data:/var/lib/postgresql/data` in the service) are managed by Docker and not directly accessible as host paths. Use named volumes for databases and other stateful data.
Production Considerations
Image size matters for production: smaller images mean faster pull times in CI/CD, less storage cost, and smaller attack surface. Target: under 100MB for most web services. Use Alpine-based images; use multi-stage builds to remove build tools; `apt-get clean && rm -rf /var/lib/apt/lists/*` after apt-get install. Health checks in production: `HEALTHCHECK –interval=30s –timeout=3s CMD curl -f http://localhost:8080/health || exit 1` — container orchestrators (Kubernetes, ECS) use health checks to determine when to stop routing traffic to a container. Read-only filesystems: `docker run –read-only` prevents writes to the container filesystem. Combined with specific volume mounts for writable areas, this prevents attackers from modifying application files. Log management: write to stdout/stderr inside containers — container orchestrators capture these and route them to your logging system. Don’t write logs to files inside containers (those logs disappear when the container dies). Resource limits: always set memory limits for production containers. A container without a memory limit can consume all available host memory, affecting other services. `deploy: resources: limits: memory: 512M` in docker-compose.yml.
