Docker Containerization
Turn an app into production-ready Docker images with multi-stage builds, smaller attack surface, and Compose-friendly layouts for deploy and CI.
Overview
docker-containerization is an agent skill most often used in Ship (also Build) that produces hardened, minimal Docker images and Compose setups using multi-stage builds and non-root runtime patterns.
Install
npx skills add https://github.com/aj-geddes/useful-ai-prompts --skill docker-containerizationWhat is this skill?
- Multi-stage Dockerfile pattern separating build and slim production runtime (Node 18 Alpine example)
- Security practices including non-root users and minimal copied artifacts
- Reference guides and best-practices sections for maintainable production containers
- Docker Compose setup for local and multi-service development
- CI/CD-oriented container pipelines and microservice packaging workflows
- Documented two-stage Node 18 Alpine build pattern in Quick Start
- Six When to Use scenarios including CI/CD pipelines and microservices
Adoption & trust: 533 installs on skills.sh; 250 GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
Your app runs locally but you lack a secure, small production Dockerfile—or your existing images are slow, rootful, and painful in CI.
Who is it for?
Indie devs packaging Node or similar web services for cloud deploy, Kubernetes, or CI-built images before go-live.
Skip if: Teams that already standardize on vendor PaaS buildpacks with no Docker maintenance, or workloads that need deep Kubernetes manifest design without any container authoring.
When should I use this skill?
Containerizing applications, creating Dockerfiles, optimizing container images, or setting up Docker Compose services.
What do I get? / Deliverables
You leave with multi-stage Dockerfile patterns, non-root execution, and Compose-ready layouts suitable for deployment pipelines and repeatable environments.
- Multi-stage Dockerfile with production-focused final stage
- Docker Compose service definitions where multi-container setup applies
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Containerization is chiefly a Ship concern: you are packaging what you built so it runs the same in staging and production. Launch is the canonical shelf because the skill centers on deployment-ready images, exposed ports, non-root runtime, and service orchestration—not feature coding.
Where it fits
You finalize a multi-stage Dockerfile so production only ships dist output and production node_modules under a non-root user.
You add a Compose file so local API and worker services match how they will run once images hit your registry.
How it compares
Skill-backed Dockerfile and Compose recipes—not a hosted registry or managed orchestration product.
Common Questions / FAQ
Who is docker-containerization for?
Solo builders and small teams who deploy with Docker or Docker Compose and want agent help writing or optimizing Dockerfiles and service definitions.
When should I use docker-containerization?
In Ship when preparing launch images and Compose stacks; in Build when containerizing integrations or dev environments that must mirror production; when optimizing image size or hardening CI container builds.
Is docker-containerization safe to install?
It is prompt-and-pattern documentation; confirm Docker daemon access policies locally and review the Security Audits panel on this Prism page before piping generated Dockerfiles into production CI.
SKILL.md
READMESKILL.md - Docker Containerization
# Docker Containerization ## Table of Contents - [Overview](#overview) - [When to Use](#when-to-use) - [Quick Start](#quick-start) - [Reference Guides](#reference-guides) - [Best Practices](#best-practices) ## Overview Build production-ready Docker containers following best practices for security, performance, and maintainability. ## When to Use - Containerizing applications for deployment - Creating Dockerfiles for new services - Optimizing existing container images - Setting up development environments - Building CI/CD container pipelines - Implementing microservices ## Quick Start Minimal working example: ```dockerfile # Multi-stage build for Node.js application # Stage 1: Build FROM node:18-alpine AS builder WORKDIR /app COPY package*.json ./ RUN npm ci --only=production COPY . . RUN npm run build # Stage 2: Production FROM node:18-alpine WORKDIR /app # Copy only production dependencies and built files COPY --from=builder /app/node_modules ./node_modules COPY --from=builder /app/dist ./dist COPY package*.json ./ # Security: Run as non-root user RUN addgroup -g 1001 -S nodejs && adduser -S nodejs -u 1001 USER nodejs EXPOSE 3000 CMD ["node", "dist/index.js"] ``` ## Reference Guides Detailed implementations in the `references/` directory: | Guide | Contents | |---|---| | [Multi-Stage Builds](references/multi-stage-builds.md) | Multi-Stage Builds | | [Optimization Techniques](references/optimization-techniques.md) | Optimization Techniques | | [Security Best Practices](references/security-best-practices.md) | Security Best Practices, Environment Configuration | | [Docker Compose for Multi-Container](references/docker-compose-for-multi-container.md) | Docker Compose for Multi-Container | | [.dockerignore File](references/dockerignore-file.md) | .dockerignore File | | [Python](references/python.md) | Python (Django/Flask), Java (Spring Boot), Go | ## Best Practices ### ✅ DO - Use official base images - Implement multi-stage builds - Run as non-root user - Use .dockerignore - Pin specific versions - Include health checks - Scan for vulnerabilities - Minimize layers - Use build caching effectively ### ❌ DON'T - Use 'latest' tag in production - Run as root user - Include secrets in images - Create unnecessary layers - Install unnecessary packages - Ignore security updates - Store data in containers # Docker Compose for Multi-Container ## Docker Compose for Multi-Container ```yaml # docker-compose.yml version: "3.8" services: app: build: context: . dockerfile: Dockerfile args: NODE_ENV: production ports: - "3000:3000" environment: - DATABASE_URL=postgresql://postgres:password@db:5432/myapp - REDIS_URL=redis://redis:6379 depends_on: db: condition: service_healthy redis: condition: service_started networks: - app-network volumes: - ./uploads:/app/uploads restart: unless-stopped db: image: postgres:15-alpine environment: POSTGRES_DB: myapp POSTGRES_PASSWORD: password volumes: - postgres-data:/var/lib/postgresql/data healthcheck: test: ["CMD-SHELL", "pg_isready -U postgres"] interval: 10s timeout: 5s retries: 5 networks: - app-network redis: image: redis:7-alpine command: redis-server --appendonly yes volumes: - redis-data:/data networks: - app-network networks: app-network: driver: bridge volumes: postgres-data: redis-data: ``` # .dockerignore File ## .dockerignore File ``` # .dockerignore node_modules npm-debug.log dist .git .env .env.local *.md !README.md .DS_Store coverage .vscode .idea