Comprehensive Docker best practices for images, containers, and production deployments. PROACTIVELY activate for: (1) writing production-ready Dockerfiles, (2) multi-stage builds for lean images, (3) base image selection (distroless, alpine, scratch, slim), (4) layer caching and ordering, (5) .docke

🚨 CRITICAL GUIDELINES Windows File Path Requirements MANDATORY: Always Use Backslashes on Windows for File Paths When using Edit or Write tools on Windows, you MUST use backslashes ( \ ) in file paths, NOT forward slashes ( / ). Examples: ❌ WRONG: D:/repos/project/file.tsx ✅ CORRECT: D:\repos\project\file.tsx This applies to: Edit tool file path parameter Write tool file path parameter All file operations on Windows systems Documentation Guidelines NEVER create new documentation files unless explicitly requested by the user. Priority : Update existing README.md files rather than creating new documentation Repository cleanliness : Keep repository root clean only README.md unless user requests otherwise Style : Documentation should be concise, direct, and professional avoid AI generated tone User preference : Only create additional .md files when user specifically asks for documentation Docker Best Practices This skill provides current Docker best practices across all aspects of container development, deployment, and operation. Image Best Practices Base Image Selection 2025 Recommended Hierarchy: 1. Wolfi/Chainguard ( cgr.dev/chainguard/ ) Zero CVE goal, SBOM included 2. Alpine ( alpine:3.19 ) ~7MB, minimal attack surface 3. Distroless ( gcr.io/distroless/ ) ~2MB, no shell 4. Slim variants ( node:20 slim ) ~70MB, balanced Key rules: Always specify exact version tags: node:20.11.0 alpine3.19 Never use latest (unpredictable, breaks reproducibility) Use official images from trusted registries Match base image to actual needs Dockerfile Structure Optimal layer ordering (least to most frequently changing): Rationale: Docker caches layers. If code changes but dependencies don't, cached dependency layers are reused, speeding up builds. Example: Multi Stage Builds Use multi stage builds to separate build dependencies from runtime: Benefits: Smaller final images (no build tools) Better security (fewer attack vectors) Faster deployment (smaller upload/download) Layer Optimization Combine commands to reduce layers and image size: .dockerignore Always create .dockerignore to exclude unnecessary files: Container Runtime Best Practices Security Resource Management Always set resource limits in production: Health Checks Implement health checks for all long running containers: Or in compose: Logging Configure proper logging to prevent disk fill up: Or system wide in /etc/docker/daemon.json : Restart Policies Docker Compose Best Practices File Structure Network Isolation Environment Variables Important: Add .env to .gitignore Provide .env.example as template Never commit secrets to version control Dependency Management Production Best Practices Image Tagging Strategy Secrets Management Never do this: Do this: Monitoring & Observability Backup Strategy Update Strategy Platform Specific Best Practices Linux Use user namespace remapping for added security Leverage native performance advantages Use Alpine for smallest images Configure SELinux/AppArmor profiles Use systemd for Docker daemon management macOS Allocate sufficient resources in Docker Desktop Use :delegated or :cached for bind mounts Consider multi platform builds for ARM (M1/M2) Limit file sharing to necessary directories Windows Choose container type: Windows or Linux Use forward slashes in paths Ensure drives are shared in Docker Desktop Be aware of line ending differences (CRLF vs LF) Consider WSL2 backend for better performance Performance Best Practices Build Performance Image Size Use multi stage builds Choose minimal base images Clean up in the same layer Use .dockerignore Remove build dependencies Runtime Performance Security Best Practices Summary Image Security: Use official, minimal base images Scan for vulnerabilities (Docker Scout, Trivy) Don't include secrets in layers Run as non root user Keep images updated Runtime Security: Drop capabilities Use read only filesystem Set resource limits Enable security options Isolate networks Use secrets management Compliance: Follow CIS Docker Benchmark Implement container scanning in CI/CD Use signed images (Docker Content Trust) Maintain audit logs Regular security reviews Common Anti Patterns to Avoid ❌ Don't: Run as root Use privileged Mount Docker socket Use latest tag Hardcode secrets Skip health checks Ignore resource limits Use huge base images Skip vulnerability scanning Expose unnecessary ports Use inefficient layer caching Commit secrets to Git ✅ Do: Run as non root Use minimal capabilities Isolate containers Tag with versions Use secrets management Implement health checks Set resource limits Use minimal images Scan regularly Apply least privilege Optimize build cache Use .env.example templates Checklist for Production Ready Images [ ] Based on official, versioned, minimal image [ ] Multi stage build (if applicable) [ ] Runs as non root user [ ] No secrets in layers [ ] .dockerignore configured [ ] Vulnerability scan passed [ ] Health check implemented [ ] Proper labeling (version, description, etc.) [ ] Efficient layer caching [ ] Resource limits defined [ ] Logging configured [ ] Signals handled correctly [ ] Security options set [ ] Documentation complete [ ] Tested on target platform(s) This skill represents current Docker best practices. Always verify against official documentation for the latest recommendations, as Docker evolves continuously.

docker-best-practices