Optimize Docker Containerization and Deployment

This skill takes on the persona of a Docker containerization expert covering six core areas: Dockerfile optimization and multi-stage builds (layer-caching order, Alpine vs distroless vs scratch base image selection), container security hardening (non-root users with specific UID/GID, secrets management outside ENV vars, capability restrictions), Docker Compose orchestration (health-check-gated service dependencies, custom networks, named-volume and secrets-file strategies), image size optimization (distroless runtime images), development workflow integration (hot-reload volume mounts, debug port exposure), and performance/resource management (CPU/memory limits, restart policies). When invoked, it first detects the existing Docker setup (docker info, Dockerfile/compose-file discovery) and matches existing patterns rather than imposing new ones, then validates any change with a no-cache build, a docker history layer review, a docker scout vulnerability scan, a runtime smoke test that execs into the container to check running processes, and a docker-compose config validation pass when Compose files are involved.

Use it for Dockerfile/Compose authoring, security hardening, image-size reduction, or diagnosing build/runtime container issues. It explicitly hands off problems outside Docker itself: Kubernetes orchestration (pods, services, ingress) goes to a kubernetes-expert, container CI/CD pipelines to a github-actions-expert, cloud-specific container services (AWS ECS/Fargate) to a devops-expert, and complex database persistence to a database-expert.

Build caching and secrets use BuildKit mount syntax rather than baking either into a layer:

FROM node:18-alpine AS deps
WORKDIR /app
COPY package*.json ./
RUN --mount=type=cache,target=/root/.npm \
    npm ci --only=production

Multi-architecture images are built with docker buildx build --platform linux/amd64,linux/arm64, and build-time secrets use a separate mount type (--mount=type=secret,id=api_key) so a value like an API key never lands in a layer. A production Compose service pattern gates startup on a healthy database (depends_on.condition: service_healthy), reads credentials from Docker secrets files (POSTGRES_PASSWORD_FILE) rather than plain environment variables, and sets both resource limits and reservations plus a restart policy with a delay and max-attempts window. Output is a working, validated Dockerfile/Compose setup plus a structured code-review checklist across five categories: Dockerfile/multi-stage, security hardening, Compose/orchestration, image size/performance, and development workflow. Each of five common problem categories - build performance, security vulnerabilities, image size, networking, and development-workflow friction - is documented as symptom, root cause, and solution: for example, slow builds (10+ minutes) with frequent cache invalidation trace to poor layer ordering or a large build context, and are fixed with multi-stage builds and .dockerignore optimization; a container over 1GB traces to build tools left in the production image, fixed by switching to a distroless base and selective artifact copying; service communication failures or DNS resolution errors typically trace to a missing custom network or a port conflict, fixed with explicit network definitions and health checks; and hot-reload failures during development usually trace to a volume-mounting mismatch, fixed by separating a development Compose target with its own bind mounts and debug port.

Works with Docker, Docker Compose, BuildKit (docker buildx), and docker scout for vulnerability scanning; hands off to kubernetes-expert, github-actions-expert, devops-expert, and database-expert for adjacent concerns. Collaboration runs both directions: this skill provides the Docker foundation DevOps deployment automation builds on, creates optimized base images for language-specific experts, establishes container standards for CI/CD integration, and defines security baselines that production orchestration then enforces.

Developers and platform engineers writing or reviewing Dockerfiles and Compose configurations who want production-grade patterns - multi-stage builds, non-root execution, health-checked orchestration, resource limits, and BuildKit-based caching and secrets - along with a documented diagnostic path (symptom, root cause, solution) for the five most common container problem categories: build performance, security vulnerabilities, image size, networking, and development-workflow friction.