docker
Docker containerization for packaging applications with dependencies into isolated, portable units ensuring consistency across development, testing, and production environments.
What this skill does
# Docker Containerization Skill ## Summary Docker provides containerization for packaging applications with their dependencies into isolated, portable units. Containers ensure consistency across development, testing, and production environments, eliminating "works on my machine" problems. ## When to Use - **Local Development**: Consistent dev environments across team members - **CI/CD Pipelines**: Reproducible build and test environments - **Microservices**: Isolated services with independent scaling - **Production Deployment**: Portable applications across cloud providers - **Database/Service Testing**: Ephemeral databases for integration tests - **Legacy Application Isolation**: Run incompatible dependencies side-by-side ## Quick Start ### 1. Create Dockerfile ```dockerfile FROM node:18-alpine WORKDIR /app COPY package*.json ./ RUN npm ci --only=production COPY . . EXPOSE 3000 CMD ["node", "server.js"] ``` ### 2. Build Image ```bash docker build -t myapp:1.0 . ``` ### 3. Run Container ```bash docker run -p 3000:3000 myapp:1.0 ``` --- ## Core Concepts ### Images vs Containers - **Image**: Read-only template with application code, runtime, and dependencies - **Container**: Running instance of an image with writable layer - **Registry**: Storage for images (Docker Hub, GitHub Container Registry) ### Layers and Caching Each Dockerfile instruction creates a layer. Docker caches unchanged layers for faster builds. ```dockerfile # GOOD: Dependencies change less frequently than code FROM python:3.11-slim COPY requirements.txt . RUN pip install -r requirements.txt # Cached unless requirements.txt changes COPY . . # Rebuild only when code changes # BAD: Invalidates cache on every code change FROM python:3.11-slim COPY . . # Changes frequently RUN pip install -r requirements.txt # Reinstalls on every build ``` ### Volumes Persistent data storage that survives container restarts. ```bash # Named volume (managed by Docker) docker run -v mydata:/app/data myapp # Bind mount (host directory) docker run -v $(pwd)/data:/app/data myapp # Anonymous volume (temporary) docker run -v /app/data myapp ``` ### Networks Containers communicate through Docker networks. ```bash # Create network docker network create mynetwork # Run containers on network docker run --network mynetwork --name db postgres docker run --network mynetwork --name app myapp # App can connect to db using hostname "db" ``` --- ## Dockerfile Basics ### Essential Instructions ```dockerfile # Base image FROM node:18-alpine # Metadata LABEL maintainer="[email protected]" LABEL version="1.0" # Set working directory WORKDIR /app # Copy files COPY package*.json ./ COPY src/ ./src/ # Run commands (creates layer) RUN npm ci --only=production # Set environment variables ENV NODE_ENV=production ENV PORT=3000 # Expose ports (documentation only) EXPOSE 3000 # Default command CMD ["node", "src/server.js"] # Alternative: ENTRYPOINT (not overridden by docker run args) ENTRYPOINT ["node"] CMD ["src/server.js"] # Default args for ENTRYPOINT ``` ### Instruction Order for Cache Efficiency ```dockerfile # 1. Base image (rarely changes) FROM python:3.11-slim # 2. System dependencies (rarely change) RUN apt-get update && apt-get install -y \ gcc \ && rm -rf /var/lib/apt/lists/* # 3. Application dependencies (change occasionally) COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt # 4. Application code (changes frequently) COPY . . # 5. Runtime configuration ENV PYTHONUNBUFFERED=1 EXPOSE 8000 CMD ["python", "manage.py", "runserver", "0.0.0.0:8000"] ``` ### .dockerignore Exclude files from build context (faster builds, smaller images). ``` # .dockerignore node_modules/ npm-debug.log .git/ .gitignore *.md .env .vscode/ __pycache__/ *.pyc .pytest_cache/ coverage/ dist/ build/ ``` --- ## Multi-Stage Builds Optimize image size by separating build and runtime stages. ### Node.js TypeScript Example ```dockerfile # Build stage FROM node:18-alpine AS builder WORKDIR /app COPY package*.json ./ RUN npm ci COPY . . RUN npm run build # Production stage FROM node:18-alpine WORKDIR /app COPY package*.json ./ RUN npm ci --only=production COPY --from=builder /app/dist ./dist EXPOSE 3000 CMD ["node", "dist/server.js"] ``` **Benefits**: - Build dependencies (TypeScript, webpack) excluded from final image - Final image: ~50MB vs ~500MB with build tools - Faster deployments and reduced attack surface ### Python Example ```dockerfile # Build stage FROM python:3.11 AS builder WORKDIR /app COPY requirements.txt . RUN pip install --user --no-cache-dir -r requirements.txt # Runtime stage FROM python:3.11-slim WORKDIR /app COPY --from=builder /root/.local /root/.local COPY . . ENV PATH=/root/.local/bin:$PATH CMD ["python", "app.py"] ``` ### Go Example (Smallest Images) ```dockerfile # Build stage FROM golang:1.21-alpine AS builder WORKDIR /app COPY go.* ./ RUN go mod download COPY . . RUN CGO_ENABLED=0 GOOS=linux go build -o server # Runtime stage (scratch = empty base image) FROM scratch COPY --from=builder /app/server /server EXPOSE 8080 ENTRYPOINT ["/server"] ``` Result: ~10MB final image containing only the compiled binary. --- ## Docker Compose Define multi-container applications in YAML. ### Basic Structure ```yaml version: '3.8' services: app: build: . ports: - "3000:3000" environment: - DATABASE_URL=postgres://db:5432/myapp depends_on: - db volumes: - ./src:/app/src # Hot reload in development db: image: postgres:15-alpine environment: POSTGRES_PASSWORD: secret POSTGRES_DB: myapp volumes: - db_data:/var/lib/postgresql/data ports: - "5432:5432" volumes: db_data: ``` ### Commands ```bash # Start all services docker-compose up # Start in background docker-compose up -d # Rebuild images docker-compose up --build # Stop services docker-compose down # Stop and remove volumes docker-compose down -v # View logs docker-compose logs -f app # Run one-off command docker-compose run app npm test ``` ### Full Stack Example ```yaml version: '3.8' services: # Frontend web: build: context: ./frontend dockerfile: Dockerfile.dev ports: - "3000:3000" volumes: - ./frontend/src:/app/src environment: - REACT_APP_API_URL=http://localhost:8000 # Backend API api: build: ./backend ports: - "8000:8000" environment: - DATABASE_URL=postgresql://postgres:secret@db:5432/myapp - REDIS_URL=redis://redis:6379 depends_on: db: condition: service_healthy redis: condition: service_started volumes: - ./backend:/app command: uvicorn main:app --host 0.0.0.0 --reload # Database db: image: postgres:15-alpine environment: POSTGRES_PASSWORD: secret POSTGRES_DB: myapp volumes: - db_data:/var/lib/postgresql/data - ./init.sql:/docker-entrypoint-initdb.d/init.sql healthcheck: test: ["CMD-SHELL", "pg_isready -U postgres"] interval: 10s timeout: 5s retries: 5 # Cache redis: image: redis:7-alpine ports: - "6379:6379" volumes: - redis_data:/data # Worker (background jobs) worker: build: ./backend command: celery -A tasks worker --loglevel=info environment: - REDIS_URL=redis://redis:6379 depends_on: - redis - db volumes: db_data: redis_data: networks: default: name: myapp_network ``` --- ## Development Workflows ### Hot Reload with Volumes #### Node.js ```yaml services: app: build: . volumes: - ./src:/app/src # Sync source code - /app/node_modules # Prevent overwriting container's node_modules command: npm run dev ``` ```dockerfile # Dockerfile.dev FROM node:18-alpine WORKDIR /app COPY package*.json ./ RUN npm install # Include dev
Related in Cloud & DevOps
appbuilder-action-scaffolder
IncludedCreate, implement, deploy, and debug Adobe Runtime actions with consistent layout, validation, and error handling. Use this skill whenever the user needs to add actions to an App Builder project, understand action structure (params, response format, web/raw actions), configure actions in the manifest, use App Builder SDKs (State, Files, Events, database), deploy and invoke actions via CLI, debug action issues, or implement patterns such as webhook receivers, custom event providers, journaling consumers, large payload redirects, action sequence pipelines, and Asset Compute workers. Also trigger when users mention serverless functions in Adobe context, action logging, IMS authentication for actions, or cron-style scheduled actions.
orchestrating-datacloud
IncludedSalesforce Data Cloud product orchestrator for connect→prepare→harmonize→segment→act workflows. Use this skill when the user needs a multi-step Data Cloud pipeline, cross-phase troubleshooting, or data space and data kit management. TRIGGER when: user needs a multi-step Data Cloud pipeline, asks to set up or troubleshoot Data Cloud across phases, manages data spaces or data kits, or wants a cross-phase sf data360 workflow. DO NOT TRIGGER when: work is isolated to a single phase (use the matching phase-specific skill), the task is STDM/session tracing/parquet telemetry (use observing-agentforce), standard CRM SOQL (use querying-soql), or Apex implementation (use generating-apex).
github-project-automation
IncludedAutomate GitHub repository setup with CI/CD workflows, issue templates, Dependabot, and CodeQL security scanning. Includes 12 production-tested workflows and prevents 18 errors: YAML syntax, action pinning, and configuration. Use when: setting up GitHub Actions CI/CD, creating issue/PR templates, enabling Dependabot or CodeQL scanning, deploying to Cloudflare Workers, implementing matrix testing, or troubleshooting YAML indentation, action version pinning, secrets syntax, runner versions, or CodeQL configuration. Keywords: github actions, github workflow, ci/cd, issue templates, pull request templates, dependabot, codeql, security scanning, yaml syntax, github automation, repository setup, workflow templates, github actions matrix, secrets management, branch protection, codeowners, github projects, continuous integration, continuous deployment, workflow syntax error, action version pinning, runner version, github context, yaml indentation error
sf-datacloud
IncludedSalesforce Data Cloud product orchestrator for connect→prepare→harmonize→segment→act workflows. TRIGGER when: user needs a multi-step Data Cloud pipeline, asks to set up or troubleshoot Data Cloud across phases, manages data spaces or data kits, or wants a cross-phase `sf data360` workflow. DO NOT TRIGGER when: work is isolated to a single phase (use the matching sf-datacloud-* skill), the task is STDM/session tracing/parquet telemetry (use sf-ai-agentforce-observability), standard CRM SOQL (use sf-soql), or Apex implementation (use sf-apex).
fabric-cli
IncludedUse this skill for Fabric.so CLI workflows with the `fabric` terminal command: diagnose/install/login, search or browse a Fabric library, save notes/links/files, create folders, ask the Fabric AI assistant, manage tasks/workspaces, generate shell completion, check subscription usage, produce JSON output, and use Fabric as persistent agent memory. Do not use for Microsoft Fabric/Azure/Power BI `fab`, Daniel Miessler's Fabric framework, Python Fabric SSH, Fabric.js, or textile/fashion fabric.
lark
IncludedLark/Feishu CLI skills: lark-cli operations for docs, markdown, sheets, base, calendar, im, mail, task, okr, drive, wiki, slides, whiteboard, apps, approval, attendance, contact, vc, minutes, event. Use when the user needs to operate Lark/Feishu resources via lark-cli, send messages, manage documents, spreadsheets, calendars, tasks, OKRs, deploy web pages, or any Feishu/Lark workspace operations.