10 Docker Best Practices for Pune DevOps (2026)

The list

1. 1

   Use multi-stage builds to reduce image size

   Pattern: `FROM node:20 AS builder` (build stage installs deps + builds) → `FROM nginx:alpine` (final stage copies only artifacts). Final image excludes build tools, source code, test files. Real impact: production images can shrink from 1.5GB → 50MB.

   Why it matters: Asked at ~70% of Pune Docker rounds. Walking through a before/after multi-stage example demonstrates real production experience.

   Best for: Smaller images + faster deploys + reduced attack surface.

2. 2

   Order Dockerfile instructions for optimal layer caching

   Put rarely-changing instructions first (FROM, base setup), frequently-changing instructions last (COPY source code). Reason: Docker caches each layer; first changed layer + all subsequent invalidate. Bad: COPY . . at top → every change re-installs npm. Good: COPY package.json + npm install first, then COPY rest.

   Why it matters: Asked at ~60% of Pune rounds. Most-common Docker performance fix; immediately visible in CI build times.

   Best for: Build speed + CI cost optimisation.

3. 3

   Use specific image tags, not latest

   Pin to specific versions: `FROM node:20.10.0-alpine` not `FROM node:latest`. Reasons: reproducible builds, no surprise breaking changes, security audit trail. Use Renovate or Dependabot to manage updates safely. `latest` in production = surprise outages waiting to happen.

   Why it matters: Asked at ~50% of Pune rounds. Walking through a 'works on my machine, broke in production' scenario via :latest signals real production maturity.

   Best for: Production reliability; reproducible builds.

4. 4

   Run containers as non-root user

   Default Docker user is root → security risk if container is breached. Best practice: create + switch to non-root user. Pattern: `RUN adduser --disabled-password appuser && USER appuser`. Most security-conscious Pune product cos + BFSI require this in CI gates.

   Why it matters: Asked at ~45% of Pune security-conscious rounds (product cos, BFSI tech). Container security signal.

   Best for: Security hardening; PCI / BFSI compliance contexts.

5. 5

   Use .dockerignore to exclude build context bloat

   Like .gitignore but for Docker. Pattern in .dockerignore: `node_modules/, .git/, *.log, .env`. Without it: Docker copies your entire repo to build context (slow + leaks credentials in .env files). Always have one; recruiters check this on portfolio projects.

   Why it matters: Asked at ~40% of Pune rounds. Quick discriminator — candidates who add it signal real Docker experience.

   Best for: Build speed + preventing credential leaks.

6. 6

   Handle secrets via build args + runtime env vars, not in image

   Never hardcode secrets in Dockerfile or COPY .env into image. Build-time secrets via `--build-arg` or BuildKit `--secret`. Runtime secrets via env vars or secret managers (AWS Secrets Manager, Vault). Image layers preserve history — committed secrets stay in image even if deleted.

   Why it matters: Asked at ~55% of Pune product company + security-conscious rounds. The #1 Docker security mistake.

   Best for: Security; credential management; compliance contexts.

7. 7

   Use HEALTHCHECK for container health monitoring

   Pattern: `HEALTHCHECK --interval=30s --timeout=3s CMD curl -f http://localhost/health || exit 1`. Container orchestrators (Kubernetes, ECS, Docker Swarm) use this for auto-restart + load-balancer routing. Without it: orchestrator can't distinguish 'process running but app broken' from 'app healthy'.

   Why it matters: Asked at ~35% of Pune production-focused rounds. Walking through orchestrator integration shows real production thinking.

   Best for: Container orchestration + auto-healing setups.

8. 8

   Set explicit resource limits in production

   Without limits: containers can consume entire host memory + CPU → noisy neighbour issues + OOM killer surprises. Set in Kubernetes Pod specs (resources.limits/requests) or `docker run --memory=512m --cpus=1.0`. Critical for multi-tenant + shared infrastructure.

   Why it matters: Asked at ~40% of Pune rounds. Walking through OOM kills + CPU throttling debugging signals real production experience.

   Best for: Multi-tenant deployments; cost predictability; reliability.

9. 9

   Use lightweight base images (alpine, distroless)

   alpine variants: ~5-10MB vs Debian's ~100MB. Distroless images (Google's): just runtime + your app, no shell or package manager → minimal attack surface. Trade-offs: alpine uses musl libc (occasionally compatibility issues); distroless lacks debugging tools. Pick based on production maturity needs.

   Why it matters: Asked at ~30% of Pune rounds. Image-size + security-conscious signal.

   Best for: Smaller images + faster pulls + security hardening.

10. 10

    Scan images for vulnerabilities (Trivy, Snyk, Grype)

    Add to CI pipeline: `trivy image yourimage:tag` scans for known CVEs in OS packages + language libraries. Fail CI on critical + high vulnerabilities. Most Pune BFSI tech + product company codebases gate on this; AI startups increasingly adopting.

    Why it matters: Asked at ~35% of Pune security-conscious + BFSI rounds. Container security awareness signal.

    Best for: Security posture; BFSI compliance; supply-chain risk management.