Optimization

Multi-Stage Builds

Use multi-stage builds to create smaller production images by separating build-time dependencies from runtime requirements:

# Build stage - includes all build dependencies and tools
FROM node:16 AS builder
WORKDIR /app
# Copy dependencies first to leverage layer caching
COPY package*.json ./
RUN npm install
# Copy application code
COPY . .
# Build the application
RUN npm run build

# Production stage - much smaller base image with only runtime requirements
FROM nginx:alpine
# Copy only the build artifacts from the builder stage
COPY --from=builder /app/build /usr/share/nginx/html
# Optional: Copy only specific files needed for runtime
COPY --from=builder /app/config/nginx.conf /etc/nginx/conf.d/default.conf
# Set non-root user for better security
USER nginx

Multi-stage builds provide several benefits:

• Dramatically smaller final images (often 10-20x reduction in size)
• Separation of build-time and runtime dependencies
• Reduced attack surface with fewer installed packages
• Better layer caching for faster rebuilds
• More secure images without build tools or source code

Minimize Layers

Docker images are composed of layers, and each layer adds overhead. Optimize by reducing unnecessary layers:

• Combine related commands into single RUN instruction
• Use && to chain commands logically
• Clean up temporary files and package caches in the same layer
• Group installations by stability/change frequency

# Bad example - each command creates a new layer
# RUN apt-get update
# RUN apt-get install -y package1
# RUN apt-get install -y package2
# RUN apt-get clean

# Good example - single layer with proper cleanup
RUN apt-get update && \
    apt-get install -y \
      package1 \
      package2 \
      --no-install-recommends && \
    apt-get clean && \
    rm -rf /var/lib/apt/lists/* && \
    # Application-specific cleanup
    rm -rf /tmp/* /var/tmp/* && \
    # Ensure all package installations succeeded
    package1 --version && package2 --version

Every layer:

• Adds metadata overhead (typically ~4KB per layer)
• Impacts build and pull times
• Affects layer cache efficiency
• Contributes to overall image size complexity

While Docker has a hard limit of 127 layers, a good rule of thumb is to aim for fewer than 20 layers in a production image.

Use .dockerignore

Create a .dockerignore file to exclude unnecessary files from the build context. This reduces build time, context size, and prevents sensitive information from being included in images:

# Version control
.git
.gitignore
.svn
.hg

# Development artifacts
node_modules
bower_components
vendor
*.o
*.obj
*.exe
__pycache__/
*.py[cod]
*$py.class
*.so
.Python
env/
build/
develop-eggs/
dist/
downloads/
eggs/
.eggs/
lib64/
parts/
sdist/
var/
.installed.cfg

# Logs and databases
*.log
logs/
*.sql
*.sqlite
*.sqlite3
*.db

# Environment and secrets
.env
.env.*
.venv
.aws/
.ssh/
.config/
.npm/
.cache/
*.pem
*.key
*_rsa
*_dsa
*_ed25519
*_ecdsa
credentials.json

# IDE files
.idea/
.vscode/
*.swp
*.swo
.DS_Store
Thumbs.db

# Testing
coverage/
.coverage
htmlcov/
.pytest_cache/
.tox/
.nox/

# Docker specific
Dockerfile*
docker-compose*
.dockerignore

Benefits of a well-configured .dockerignore:

• Reduces build context size (can improve build time by orders of magnitude)
• Prevents unnecessary cache invalidation
• Improves security by excluding secrets and credentials
• Makes builds more deterministic by excluding variable content
• Reduces bandwidth usage when transferring build context to remote Docker daemons

You can also use pattern matching similar to .gitignore:

• **/temp* - matches any file or directory starting with "temp"
• !important.log - negates a previous pattern, including important.log
• #comment - comments for documentation

Choose Appropriate Base Images

Base image selection significantly impacts image size, security, and performance:

• Use official slim or alpine variants
  • Alpine: Extremely small (~5MB) but uses musl libc instead of glibc
  • Slim variants: Trimmed official images with minimal packages (~40-60MB)
  • Debian/Ubuntu-based images: Better compatibility but larger size
• Consider distroless images for production
  • Contains only your application and its runtime dependencies
  • No package manager, shell, or other utilities
  • Minimal attack surface and smaller size
  • Examples: gcr.io/distroless/java, gcr.io/distroless/nodejs
  • Challenging to debug but excellent for security
• Be specific with image tags
  • Always use explicit version tags (e.g., node:16.14.2-alpine3.15)
  • Avoid latest tag for reproducible builds
  • Consider using image digests for immutability: node@sha256:3e36d7d8458e14...
  • Balance freshness with stability when choosing versions
• Choose based on application requirements
  • CPU architecture compatibility (x86_64, ARM64, etc.)
  • Required system libraries and dependencies
  • Security patch update frequency
  • Community support and documentation

Base image size comparison:

node:16                 # ~910MB
node:16-slim            # ~175MB
node:16-alpine          # ~110MB
gcr.io/distroless/nodejs:16  # ~80MB

Consider creating standardized, security-hardened base images for your organization that include common configurations, monitoring agents, and security patches.

Resource Constraints

Setting appropriate resource limits prevents containers from consuming excessive resources or affecting neighboring containers:

# Limit CPU and memory
docker run -d --name app \
  # Limit to 1.5 CPU cores (CPU shares)
  --cpus=1.5 \
  # Hard memory limit (container is killed if exceeded)
  --memory=512m \
  # Soft memory reservation (container attempts to stay below)
  --memory-reservation=256m \
  # Memory swappiness (0-100, lower = less swapping)
  --memory-swappiness=0 \
  # CPU scheduling priority
  --cpu-shares=1024 \
  # Restrict to specific CPU cores
  --cpuset-cpus="0,1" \
  # Limit PIDs (prevents fork bombs)
  --pids-limit=100 \
  # Block I/O weights
  --blkio-weight=500 \
  # Set ulimits
  --ulimit nofile=8192:16384 \
  # OOM score adjustment (-1000 to 1000, lower = less likely to be killed)
  --oom-score-adj=500 \
  my-app:latest

These constraints provide several benefits:

• Predictable performance through resource isolation
• Protection against noisy neighbor problems
• Improved host stability by preventing resource exhaustion
• More accurate capacity planning and scheduling
• Better Quality of Service (QoS) management

Resource constraints should be tailored to each application's needs and based on performance profiling rather than arbitrary values.

Read-Only Filesystem

Using read-only filesystems provides significant security benefits by preventing modification of container contents at runtime:

# Mount root filesystem as read-only
docker run -d --name app \
  # Make the entire filesystem read-only
  --read-only \
  # Allow specific directories to be writable using tmpfs (in-memory)
  --tmpfs /tmp:rw,size=256m,mode=1777 \
  --tmpfs /var/run:rw,size=64m \
  --tmpfs /var/cache:rw,size=128m \
  # Mount a specific volume for data that needs persistence
  -v app-data:/data:rw \
  # Mount specific host directories as read-only
  -v /etc/config:/etc/app-config:ro \
  # Set security options
  --security-opt="no-new-privileges:true" \
  my-app:latest

This approach:

• Prevents runtime modification of application binaries
• Mitigates the impact of certain types of attacks
• Forces proper externalization of persistent data
• Makes containers more immutable and predictable
• Helps identify application assumptions about filesystem access

Applications may require adaptation to work with read-only filesystems, particularly those that attempt to write to their installation directories or expect to create temporary files in non-standard locations.

Proper Stop Signal

Configuring appropriate stop signals ensures graceful container termination, preventing data corruption and service disruption:

# Define stop signal in Dockerfile
STOPSIGNAL SIGTERM

# Override stop signal at runtime
docker run -d --stop-signal SIGTERM my-app:latest

# Configure stop timeout (seconds before SIGKILL)
docker run -d --stop-timeout=30 my-app:latest

Understanding container lifecycle signals:

1. SIGTERM (default): Requests graceful termination, allows cleanup
2. SIGKILL: Immediate forceful termination, no cleanup possible
3. SIGINT: Terminal interrupt (like Ctrl+C), may be handled differently
4. SIGHUP: Terminal disconnect, some applications use for config reload

Proper termination handling includes:

• Application traps and handles SIGTERM
• Completes in-progress transactions
• Closes database connections properly
• Finishes writing to disk and flushes buffers
• De-registers from service discovery
• Returns appropriate exit code

For custom applications, implement proper signal handlers:

// Node.js example
process.on('SIGTERM', async () => {
  console.log('Graceful shutdown initiated');
  await closeConnections();
  await flushBuffers();
  console.log('Graceful shutdown completed');
  process.exit(0);
});

Healthchecks

Healthchecks help Docker monitor container health and automatically restart unhealthy containers. They distinguish between running containers and properly functioning applications:

# Add healthcheck to Dockerfile
HEALTHCHECK --interval=30s --timeout=3s --start-period=60s --retries=3 \
  CMD curl -f http://localhost/health || exit 1

# Define healthcheck at runtime
docker run -d --name app \
  --health-cmd="curl -f http://localhost:8080/actuator/health || exit 1" \
  --health-interval=30s \
  --health-timeout=5s \
  --health-retries=3 \
  --health-start-period=60s \
  my-app:latest

Healthcheck parameters explained:

• interval: Time between checks (default: 30s)
• timeout: Maximum time for check to complete (default: 30s)
• start-period: Grace period for initialization (default: 0s)
• retries: Number of consecutive failures before unhealthy (default: 3)

Effective healthcheck commands should:

• Be lightweight and quick to execute
• Check critical application functionality
• Have minimal dependencies
• Return appropriate exit codes (0 = healthy, 1 = unhealthy)
• Avoid false positives/negatives
• Include reasonable timeouts

Examples for different application types:

# Web application
HEALTHCHECK CMD curl -f http://localhost/ || exit 1

# Database
HEALTHCHECK CMD pg_isready -U postgres || exit 1

# API service
HEALTHCHECK CMD wget -O- http://localhost:8080/actuator/health | grep UP || exit 1

# Worker/background service
HEALTHCHECK CMD pgrep -f worker.js || exit 1

Healthchecks enable orchestration platforms to make intelligent scheduling decisions and provide automatic remediation for failed containers.

Memory Limits

• Set appropriate memory limits
  • Based on application profiling, not guesswork
  • Include headroom for garbage collection and peak usage
  • Consider both resident set size (RSS) and virtual memory
  • Balance between too restrictive (crashes) and too generous (waste)
  • Example: --memory=512m --memory-reservation=384m
  • Different applications have different memory usage patterns:
    • JVM: Consider heap size + metaspace + native memory
    • Node.js: V8 heap + buffer allocations
    • Python: Interpreter overhead + application memory
• Configure swap behavior
  • --memory-swap: Total memory+swap limit
  • --memory-swappiness=0: Reduce swapping to minimum
  • Disable swap entirely for latency-sensitive applications
  • For databases, configure appropriate swappiness
  • Example: --memory=1g --memory-swap=1g (no swap)
• Monitor memory usage
  • Track both current and peak memory usage
  • Identify memory leaks with trending data
  • Monitor garbage collection frequency and duration
  • Analyze OOM kill events
  • Tools: docker stats, cAdvisor, Prometheus metrics
  • Commands:
    # Live memory usage
    docker stats --no-stream --format "table {{.Name}}\t{{.MemUsage}}"
    
    # Container memory details
    docker inspect $(docker ps -q) | jq '.[].HostConfig.Memory'
    

• Use cgroup constraints
  • Kernel memory limits: --kernel-memory=64m
  • CPU and memory pressure correlation
  • Soft vs hard limits: reservation vs limit
  • cgroup v2 support for improved memory accounting
  • Example: --memory-reservation=256m --memory=512m
• Implement OOM handling
  • --oom-kill-disable: Prevent OOM killer (use carefully)
  • --oom-score-adj: Adjust OOM kill priority (-1000 to 1000)
  • Proper application-level error handling
  • Graceful degradation under memory pressure
  • Health monitoring to detect memory-related issues
  • OOM-aware application design
  • Example: --oom-score-adj=-500 (less likely to be killed)

Memory Settings in Compose

Define comprehensive memory constraints in Docker Compose for reproducible multi-container deployments:

version: '3.8'
services:
  app:
    image: my-app:latest
    deploy:
      resources:
        limits:
          memory: 512M  # Hard limit - container is killed if exceeded
          cpus: '0.5'   # CPU limits often affect memory usage patterns
        reservations:
          memory: 256M  # Soft limit - guaranteed minimum memory
          cpus: '0.25'  # Guaranteed CPU reservation
    environment:
      # Application-specific memory settings
      JAVA_OPTS: "-Xms256m -Xmx384m -XX:MaxMetaspaceSize=128m"
      NODE_OPTIONS: "--max-old-space-size=384"
    # Additional memory-related settings
    ulimits:
      memlock: -1  # Unlimited memlock for databases
    # OOM settings (requires host privileges)
    oom_score_adj: 500  # Higher value = higher chance of being killed by OOM killer
    # Memory swappiness control (0-100)
    mem_swappiness: 0   # Prefer to drop page cache than swap out memory
    # If using compose with swarm:
    restart_policy:
      condition: on-failure
      max_attempts: 3
      delay: 5s

  database:
    image: postgres:13
    deploy:
      resources:
        limits:
          memory: 1G
        reservations:
          memory: 512M
    environment:
      POSTGRES_PASSWORD: example
      # Database memory tuning
      POSTGRES_SHARED_BUFFERS: 256MB
      POSTGRES_EFFECTIVE_CACHE_SIZE: 768MB
      POSTGRES_WORK_MEM: 16MB

For production use, consider these additional memory optimization techniques:

• Setting JVM/runtime-specific memory flags via environment variables
• Adjusting application server parameters (workers, threads, connection pools)
• Fine-tuning database memory allocation parameters
• Implementing graceful degradation under memory pressure
• Using health checks that monitor memory usage

Monitoring Memory

Comprehensive memory monitoring helps identify issues before they cause outages and provides data for proper sizing:

# Check container memory usage with pretty table format
docker stats --no-stream --format "table {{.Name}}\t{{.MemUsage}}\t{{.MemPerc}}\t{{.CPUPerc}}"

# Get detailed memory stats in JSON format for processing
docker stats --no-stream --format "{{json .}}" container_name | jq '.'

# Extract specific memory metrics
docker stats --no-stream --format "{{.MemUsage}}" container_name | awk '{print $1}'

# Monitor memory usage over time (samples every 5 seconds)
while true; do 
  docker stats --no-stream --format "{{.Name}},{{.MemUsage}},{{.MemPerc}}" >> memory_log.csv
  sleep 5
done

# Check kernel memory events (OOM kills)
dmesg | grep -i "out of memory"

# Inspect container memory limits
docker inspect --format '{{.HostConfig.Memory}}' container_name

# For detailed memory metrics, use cAdvisor or Prometheus
# Example metrics to track:
# - container_memory_usage_bytes
# - container_memory_cache
# - container_memory_rss
# - container_memory_swap
# - container_memory_failcnt (memory limit hit count)
# - container_memory_mapped_file

# Find containers with no memory limits
docker ps -q | xargs docker inspect -f '{{.Name}} {{.HostConfig.Memory}}' | grep " 0$"

# Memory reservation vs actual usage comparison
docker ps -q | xargs docker inspect -f '{{.Name}}: Limit={{.HostConfig.Memory}} Reservation={{.HostConfig.MemoryReservation}}' | sort

Advanced memory analysis tools:

• cAdvisor for detailed container memory metrics
• Prometheus + Grafana for visualization and alerting
• docker-top for process-level memory visibility within containers
• memory-profiler for application-specific memory analysis
• pmap for process memory mapping (requires privileged access)

Memory usage patterns

Daemon Configuration

Edit /etc/docker/daemon.json to configure global settings:

{
  "default-ulimits": {
    "nofile": {
      "Name": "nofile",
      "Hard": 64000,
      "Soft": 64000
    },
    "nproc": {
      "Name": "nproc",
      "Hard": 32768,
      "Soft": 32768
    }
  },
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3",
    "compress": "true"
  },
  "max-concurrent-downloads": 10,
  "max-concurrent-uploads": 10,
  "storage-driver": "overlay2",
  "storage-opts": [
    "overlay2.override_kernel_check=true",
    "overlay2.size=20G"
  ],
  "registry-mirrors": [
    "https://mirror.gcr.io",
    "https://registry-1.docker.io"
  ],
  "dns": ["8.8.8.8", "8.8.4.4"],
  "default-address-pools": [
    {"base": "172.30.0.0/16", "size": 24}
  ],
  "experimental": true,
  "metrics-addr": "0.0.0.0:9323",
  "features": {
    "buildkit": true
  },
  "live-restore": true,
  "default-runtime": "runc",
  "exec-opts": ["native.cgroupdriver=systemd"],
  "init": true,
  "no-new-privileges": true,
  "icc": false
}

Important daemon settings to consider:

• storage-driver: Select appropriate driver for workload (overlay2 recommended)
• live-restore: Keep containers running during daemon restart
• max-concurrent-downloads/uploads: Adjust based on network and disk I/O
• registry-mirrors: Set up pull-through cache for frequently used images
• default-runtime: Select container runtime (runc, containerd, etc.)
• init: Always use init process for better signal handling and zombie prevention
• icc: Inter-container communication controls (false for better security)
• default-ulimits: Set appropriate file descriptor and process limits
• metrics-addr: Enable Prometheus metrics endpoint

Logging Configuration

• Use appropriate log drivers
  • json-file: Default, stores logs as JSON files on host
  • local: Newer optimized local logging driver
  • syslog: Forward to syslog daemon
  • journald: Forward to systemd journal
  • splunk, awslogs, gelf: Send to external logging systems
  • none: Disable logging for performance-critical applications
• Configure log rotation
  • Set max-size to limit individual log file size
  • Set max-file to control number of log files to retain
  • Enable compress to reduce disk usage
  • Consider time-based rotation for compliance requirements
  • Implement host-level log management for Docker's own logs
• Consider centralized logging
  • Aggregate container logs in Elasticsearch, Splunk, or similar
  • Implement structured logging for better searchability
  • Configure proper retention policies for different log types
  • Set up monitoring and alerting based on log patterns
  • Preserve logs from ephemeral containers
• Limit log file size
  • Prevent disk space exhaustion from chatty containers
  • Set appropriate limits based on application verbosity
  • Monitor log volume and growth rate
  • Alert on unusual log volume increases
  • Implement emergency pruning for runaway logging
• Control logging verbosity
  • Configure application log levels appropriately
  • Filter irrelevant logs before storage
  • Implement sampling for high-volume log sources
  • Use environment variables to control log verbosity
  • Consider different verbosity for different environments

System-level Optimizations

• Increase file descriptor limits in host OS
• Configure appropriate I/O scheduler for storage devices
• Adjust kernel parameters for container workloads:
  # /etc/sysctl.conf adjustments
  fs.file-max = 2097152
  fs.inotify.max_user_watches = 524288
  vm.max_map_count = 262144
  net.ipv4.ip_forward = 1
  

• Disable SWAP for predictable container performance
• Use high-performance storage for Docker data directory
• Configure appropriate CPU governor for workload type

Benchmarking

• Use Docker stats for real-time metrics
  # Live monitoring with custom columns
  docker stats --format "table {{.Name}}\t{{.CPUPerc}}\t{{.MemUsage}}\t{{.MemPerc}}\t{{.NetIO}}\t{{.BlockIO}}"
  
  # Capture point-in-time statistics
  docker stats --no-stream > stats-$(date +%Y%m%d-%H%M%S).txt
  
  # Measure startup time
  time docker run --name test-startup my-app:latest
  

• Implement application-level metrics
  • Instrument code with Prometheus client libraries
  • Measure critical business operations latency
  • Track resource utilization from within the application
  • Monitor cache hit rates and database query performance
  • Example metrics to track:
    • Request latency percentiles (p50, p95, p99)
    • Request throughput (requests per second)
    • Error rates and types
    • Business transactions per second
    • Queue depths and processing times
• Compare before and after optimizations
  • Create reproducible benchmark scenarios
  • Document baseline performance metrics
  • Isolate variables when testing changes
  • Measure impact on both average and tail latencies
  • Consider cost implications of optimizations
  • Example benchmarking workflow:
    # Run load test on current version
    ./load-test.sh --target=v1 --duration=10m > results-v1.txt
    
    # Apply optimization
    docker build -t my-app:v2 -f Dockerfile.optimized .
    
    # Run identical load test on optimized version
    ./load-test.sh --target=v2 --duration=10m > results-v2.txt
    
    # Compare results
    ./compare-results.sh results-v1.txt results-v2.txt
    

• Track build and startup times
  • Measure full CI/CD pipeline duration
  • Break down build phases for targeted optimization
  • Track image pull times in different environments
  • Measure time-to-first-request for applications
  • Monitor cold start vs. warm start performance
  • Example measurement script:
    #!/bin/bash
    echo "Build time:"
    time docker build -t test-app .
    
    echo "Image size:"
    docker images test-app --format "{{.Size}}"
    
    echo "Pull time (simulated):"
    docker save test-app | wc -c | awk '{print $1/1024/1024 " MB"}'
    docker rmi test-app
    time docker load < test-app.tar
    
    echo "Startup time:"
    time docker run --rm test-app
    

• Measure image sizes
  • Track layer composition and sizes
  • Compare compressed vs. uncompressed image sizes
  • Analyze image composition with tools like dive
  • Correlate image size with pull time
  • Track evolution of image size over time
  • Example commands:
    # Basic image size
    docker images my-app
    
    # Detailed breakdown with dive
    docker run --rm -it -v /var/run/docker.sock:/var/run/docker.sock wagoodman/dive:latest my-app:latest
    
    # Layer sizes and history
    docker history --no-trunc --format "table {{.CreatedBy}}\t{{.Size}}" my-app:latest
    
    # Calculate compressed size (approximating pull size)
    docker save my-app:latest | gzip -c | wc -c
    

Monitoring Tools

• Docker stats: Basic built-in resource monitoring
  # Continuous monitoring of all containers
  docker stats
  
  # Custom format for specific metrics
  docker stats --format "table {{.Name}}\t{{.CPUPerc}}\t{{.MemUsage}}"
  

• cAdvisor: Container-specific metrics with historical data
  # Run cAdvisor container
  docker run \
    --volume=/:/rootfs:ro \
    --volume=/var/run:/var/run:ro \
    --volume=/sys:/sys:ro \
    --volume=/var/lib/docker/:/var/lib/docker:ro \
    --publish=8080:8080 \
    --detach=true \
    --name=cadvisor \
    --privileged \
    --device=/dev/kmsg \
    gcr.io/cadvisor/cadvisor:v0.45.0
  

• Prometheus: Time-series metrics storage and querying
  • Collect container and host metrics
  • Store historical performance data
  • Create alerts based on performance thresholds
  • PromQL examples for container monitoring:
    # CPU utilization by container
    rate(container_cpu_usage_seconds_total{name=~".+"}[1m])
    
    # Memory usage by container
    container_memory_usage_bytes{name=~".+"}
    
    # Disk I/O by container
    rate(container_fs_reads_bytes_total{name=~".+"}[1m])
    

• Grafana dashboards: Visualization and dashboarding
  • Create custom dashboards for different stakeholders
  • Set up alerts based on performance thresholds
  • Visualize trends over time
  • Correlate metrics across system components
  • Example dashboard panels:
    • Container CPU and memory usage
    • Network I/O by container
    • Disk operations and throughput
    • Application-specific metrics
    • Health check status and history
• Docker Desktop metrics: Local development monitoring
  • Resource usage monitoring in Docker Desktop
  • Container inspection and troubleshooting
  • Network traffic visualization
  • Disk usage analysis
  • Extension plugins for enhanced monitoring
• Specialized monitoring tools
  • Sysdig: Deep container and system monitoring
  • Datadog: Commercial APM and infrastructure monitoring
  • New Relic: Application and infrastructure performance
  • Dynatrace: Full-stack monitoring with AI capabilities
  • Elastic APM: Open-source application performance monitoring

Image Optimization

• Multi-stage builds
  • Separate build-time and runtime dependencies
  • Use appropriate base images for each stage
  • Copy only necessary artifacts between stages
  • Consider separate stages for testing and production
• Minimal base images
  • Use lightweight variants (alpine, slim, distroless)
  • Remove unnecessary packages and tools
  • Select appropriate base for compatibility vs. size
  • Consider custom organizational base images
  • Keep base images updated for security
• Layer optimization
  • Combine related operations in single RUN instructions
  • Order layers from least to most frequently changed
  • Clean up package manager caches in same layer
  • Use multi-line arguments for readability
  • Keep layer count reasonable (under 20 layers)
• Proper caching
  • Leverage BuildKit's enhanced caching
  • Use .dockerignore to prevent unnecessary context
  • Split dependencies and application code
  • Consider explicit cache mounting for dependencies
  • Implement registry-based caching for CI/CD
• Efficient COPY and RUN
  • Copy only what's needed (avoid COPY . .)
  • Use wildcard patterns for related files
  • Implement chained commands with proper cleanup
  • Set appropriate working directories
  • Use ADD only when extract functionality is needed

Build Optimization

• BuildKit enabled
  • Set DOCKER_BUILDKIT=1 environment variable
  • Configure in daemon.json for system-wide usage
  • Use BuildKit-specific features when appropriate
  • Implement SSH and secret mounting for secure builds
  • Leverage parallel stage execution
• Ordered instructions
  • Place infrequently changing commands first
  • Group related commands logically
  • Split long RUN commands strategically
  • Organize for maximum cache efficiency
  • Maintain readability and maintainability
• Build caching
  • Implement proper layer caching strategy
  • Use cache mounts for package managers
  • Consider external cache storage for CI/CD
  • Implement cache warming for frequently built images
  • Cleanup unused cache periodically
• CI/CD integration
  • Configure appropriate caching in pipelines
  • Implement matrix builds where appropriate
  • Use build arguments for environment-specific builds
  • Tag images with meaningful metadata
  • Implement vulnerability scanning in pipeline
• Parallel builds
  • Design multi-stage builds for parallelization
  • Keep stages independent where possible
  • Leverage BuildKit's automatic parallelization
  • Scale build infrastructure appropriately
  • Monitor build performance metrics

Runtime Optimization

• Resource limits
  • Set appropriate CPU and memory constraints
  • Configure proper swap behavior
  • Implement resource monitoring
  • Use resource reservations in orchestration
  • Balance resource efficiency and reliability
• Proper networking
  • Select appropriate network drivers
  • Configure DNS settings optimally
  • Implement connection pooling
  • Consider service mesh for complex applications
  • Monitor network performance metrics
• Volume optimization
  • Use appropriate volume drivers for workloads
  • Implement caching strategies for mounted volumes
  • Configure proper mount options
  • Monitor volume performance
  • Consider specialized storage for I/O-intensive workloads
• Logging configuration
  • Select appropriate logging drivers
  • Implement log rotation and size limits
  • Consider structured logging formats
  • Configure centralized logging
  • Implement log level management
• Monitoring setup
  • Deploy comprehensive container monitoring
  • Implement health checks
  • Configure alerts for resource constraints
  • Track application-specific metrics
  • Implement tracing for distributed systems