跳到主内容
智客 ZICQ

技能库 智客分类:运维与云 docker-best-practices

Docker Best Practices

图像、容器和生产部署方面的综合Docker最佳做法。 积极激活:(1) 写出生产准备的多克文件;(2) 用于精细图像的多相构件;(3) 基本图像选择(不清晰、高山、刮痕、瘦小);(4) 地层缓冲和订购;(5) .dockerignore 卫生;(6) HEALTHCHECK和优雅的停产;(7) 非根本用户和最优等模式;(8) ENV vs ARG和秘密处理;(9) 标记/最细指针和可复制;(10) 为当地发展作曲。 规定: 按语言分类的多克文件模板,图像大小优化核对表,.dockerignore模板,HEALTHCHECK模式,以及Compose dev-stack实例.

948 安装量

官方网址:skills.sh

技能介绍

先看中文介绍;官方 description 原文单独保留,不改写 SKILL.md。

做什么

图像、容器和生产部署方面的综合Docker最佳做法。 积极激活:(1) 写出生产准备的多克文件;(2) 用于精细图像的多相构件;(3) 基本图像选择(不清晰、高山、刮痕、瘦小);(4) 地层缓冲和订购;(5) .dockerignore 卫生;(6) HEALTHCHECK和优雅的停产;(7) 非根本用户和最优等模式;(8) ENV vs ARG和秘密处理;(9) 标记/最细指针和可复制;(10) 为当地发展作曲。 规定: 按语言分类的多克文件模板,图像大小优化核对表,.dockerignore模板,HEALTHCHECK模式,以及Compose dev-stack实例.

何时用

官方 description 未单独写出 Use when。按规范,代理会在用户任务与这段 description 的关键词匹配时激活本技能。

代理如何加载

按 Agent Skills 渐进披露:启动时只加载 name 与 description(约 100 token);任务匹配后才读入整份 SKILL.md 正文;scripts/、references/、assets/ 仅在需要时再读。 本文件正文结构:🚨 CRITICAL GUIDELINES、Windows File Path Requirements、Documentation Guidelines、Docker Best Practices、Image Best Practices、Base Image Selection。

文件分析

文件分析:这是一份仅含 SKILL.md 的指令型技能,代理激活后整份正文进入上下文。 正文约 651 行,超过规范建议的 500 行,激活时仍会整份载入。

官方 description(原文)

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) .dockerignore hygiene, (6) HEALTHCHECK and graceful shutdown, (7) non-root user and least-privilege patterns, (8) ENV vs ARG and secret handling, (9) tag/digest pinning and reproducibility, (10) Compose for local development. Provides: Dockerfile templates by language, image-size optimization checklist, .dockerignore template, HEALTHCHECK patterns, and Compose dev-stack examples.

🚨 CRITICAL GUIDELINESWindows File Path RequirementsDocumentation GuidelinesDocker Best PracticesImage Best PracticesBase Image SelectionDockerfile Structure1. System packages (rarely change)2. Dependencies (change occasionally)3. Application code (changes frequently)Multi-Stage BuildsBuild stage

来源分类:skills.sh agent-skill

SKILL.md 与 Agent 调用

官方规范 ↗
name
docker-best-practices
description
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) .dockerignore hygiene, (6) HEALTHCHECK and graceful shutdown, (7) non-root user and least-privilege patterns, (8) ENV vs ARG and secret handling, (9) tag/digest pinning and reproducibility, (10) Compose for local development. Provides: Dockerfile templates by language, image-size optimization checklist, .dockerignore template, HEALTHCHECK patterns, and Compose dev-stack examples.
  1. 发现技能客户端向 Agent 提供名称与描述目录。
  2. 匹配与调用用户指定或任务匹配后,载入 SKILL.md 指令。
  3. 按需加载按步骤读取参考文档、使用脚本与素材。

具体调用语法与可用工具以目标 Agent 客户端为准。 查看调用机制说明 ↗

安装这个技能

Skills CLI ↗

先选择目标 Agent 和安装范围,保留技能包的附属文件,安装后检查客户端能否发现该技能。

交给 Agent 安装

复制安装指令给支持 Agent Skills 的代理,确认其中的目标目录与客户端匹配。

把 Agent Skill「docker-best-practices」安装到我的项目:SKILL.md 原文与官方 description 见 https://zicq.com/zh/skills/skl-97484861300cf84b-Docker-Best-Practices.html
请存为 .cursor/skills/docker-best-practices/SKILL.md 或 .claude/skills/docker-best-practices/SKILL.md,frontmatter 的 name 与 description 保持原样,不要改写。

GitHub 完整包 ↗

终端安装 · Skills CLI

需要 Node.js 与 npx。先查看仓库技能列表,确认实际名称。

npx skills add 'https://github.com/josiahsiegel/claude-plugin-marketplace' --list

npx skills add 'https://github.com/josiahsiegel/claude-plugin-marketplace' --skill 'docker-best-practices'

CLI 会交互选择目标 Agent,默认安装到项目;用户级安装使用 -g。先通过查看命令核对仓库内容,再用 npx skills list 检查已安装技能。

阅读排版

name: docker-best-practices description: | 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) .dockerignore hygiene, (6) HEALTHCHECK and graceful shutdown, (7) non-root user and least-privilege patterns, (8) ENV vs ARG and secret handling, (9) tag/digest pinning and reproducibility, (10) Compose for local development. Provides: Dockerfile templates by language, image-size optimization checklist, .dockerignore template, HEALTHCHECK patterns, and Compose dev-stack examples.

🚨 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):

1. Base image and system dependencies
2. Application dependencies (package.json, requirements.txt, etc.)
3. Application code
4. Configuration and metadata

Rationale: Docker caches layers. If code changes but dependencies don't, cached dependency layers are reused, speeding up builds.

Example:

FROM python:3.12-slim

# 1. System packages (rarely change)
RUN apt-get update && apt-get install -y --no-install-recommends \
    gcc \
    && rm -rf /var/lib/apt/lists/*

# 2. Dependencies (change occasionally)
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

# 3. Application code (changes frequently)
COPY . /app
WORKDIR /app

CMD ["python", "app.py"]

Multi-Stage Builds

Use multi-stage builds to separate build dependencies from runtime:

# Build stage
FROM node:20-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build

# Production stage
FROM node:20-alpine AS runtime
WORKDIR /app
# Only copy what's needed for runtime
COPY --from=builder /app/dist ./dist
COPY --from=builder /app/node_modules ./node_modules
USER node
CMD ["node", "dist/server.js"]

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:

# Bad - 3 layers, cleanup doesn't reduce size
RUN apt-get update
RUN apt-get install -y curl
RUN rm -rf /var/lib/apt/lists/*

# Good - 1 layer, cleanup effective
RUN apt-get update && \
    apt-get install -y --no-install-recommends curl && \
    rm -rf /var/lib/apt/lists/*

.dockerignore

Always create .dockerignore to exclude unnecessary files:

# Version control
.git
.gitignore

# Dependencies
node_modules
__pycache__
*.pyc

# IDE
.vscode
.idea

# OS
.DS_Store
Thumbs.db

# Logs
*.log
logs/

# Testing
coverage/
.nyc_output
*.test.js

# Documentation
README.md
docs/

# Environment
.env
.env.local
*.local

Container Runtime Best Practices

Security

docker run \
  # Run as non-root
  --user 1000:1000 \
  # Drop all capabilities, add only needed ones
  --cap-drop=ALL \
  --cap-add=NET_BIND_SERVICE \
  # Read-only filesystem
  --read-only \
  # Temporary writable filesystems
  --tmpfs /tmp:noexec,nosuid \
  # No new privileges
  --security-opt="no-new-privileges:true" \
  # Resource limits
  --memory="512m" \
  --cpus="1.0" \
  my-image

Resource Management

Always set resource limits in production:

# docker-compose.yml
services:
  app:
    deploy:
      resources:
        limits:
          cpus: '2.0'
          memory: 1G
        reservations:
          cpus: '1.0'
          memory: 512M

Health Checks

Implement health checks for all long-running containers:

HEALTHCHECK --interval=30s --timeout=3s --retries=3 --start-period=40s \
  CMD curl -f http://localhost:3000/health || exit 1

Or in compose:

services:
  app:
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost/health"]
      interval: 30s
      timeout: 3s
      retries: 3
      start_period: 40s

Logging

Configure proper logging to prevent disk fill-up:

services:
  app:
    logging:
      driver: "json-file"
      options:
        max-size: "10m"
        max-file: "3"

Or system-wide in /etc/docker/daemon.json:

{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  }
}

Restart Policies

services:
  app:
    # For development
    restart: "no"

    # For production
    restart: unless-stopped

    # Or with fine-grained control (Swarm mode)
    deploy:
      restart_policy:
        condition: on-failure
        delay: 5s
        max_attempts: 3
        window: 120s

Docker Compose Best Practices

File Structure

# No version field needed (Compose v2.40.3+)

services:
  # Service definitions
  web:
    # ...
  api:
    # ...
  database:
    # ...

networks:
  # Custom networks (preferred)
  frontend:
  backend:
    internal: true

volumes:
  # Named volumes (preferred for persistence)
  db-data:
  app-data:

configs:
  # Configuration files (Swarm mode)
  app-config:
    file: ./config/app.conf

secrets:
  # Secrets (Swarm mode)
  db-password:
    file: ./secrets/db_pass.txt

Network Isolation

networks:
  frontend:
    driver: bridge
  backend:
    driver: bridge
    internal: true  # No external access

services:
  web:
    networks:
      - frontend

  api:
    networks:
      - frontend
      - backend

  database:
    networks:
      - backend  # Not accessible from frontend

Environment Variables

services:
  app:
    # Load from file (preferred for non-secrets)
    env_file:
      - .env

    # Inline for service-specific vars
    environment:
      - NODE_ENV=production
      - LOG_LEVEL=info

    # For Swarm mode secrets
    secrets:
      - db_password

Important:

  • Add .env to .gitignore
  • Provide .env.example as template
  • Never commit secrets to version control

Dependency Management

services:
  api:
    depends_on:
      database:
        condition: service_healthy  # Wait for health check
      redis:
        condition: service_started   # Just wait for start

Production Best Practices

Image Tagging Strategy

# Use semantic versioning
my-app:1.2.3
my-app:1.2
my-app:1
my-app:latest

# Include git commit for traceability
my-app:1.2.3-abc123f

# Environment tags
my-app:1.2.3-production
my-app:1.2.3-staging

Secrets Management

Never do this:

# BAD - secret in layer history
ENV API_KEY=secret123
RUN echo "password" > /app/config

Do this:

# Use Docker secrets (Swarm) or external secret management
docker secret create db_password ./password.txt

# Or mount secrets at runtime
docker run -v /secure/secrets:/run/secrets:ro my-app

# Or use environment files (not in image)
docker run --env-file /secure/.env my-app

Monitoring & Observability

services:
  app:
    # Health checks
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost/health"]
      interval: 30s

    # Labels for monitoring tools
    labels:
      - "prometheus.io/scrape=true"
      - "prometheus.io/port=9090"
      - "com.company.team=backend"
      - "com.company.version=1.2.3"

    # Logging
    logging:
      driver: "json-file"
      options:
        max-size: "10m"
        max-file: "3"

Backup Strategy

# Backup named volume
docker run --rm \
  -v VOLUME_NAME:/data \
  -v $(pwd):/backup \
  alpine tar czf /backup/backup-$(date +%Y%m%d).tar.gz -C /data .

# Restore volume
docker run --rm \
  -v VOLUME_NAME:/data \
  -v $(pwd):/backup \
  alpine tar xzf /backup/backup.tar.gz -C /data

Update Strategy

services:
  app:
    # For Swarm mode - rolling updates
    deploy:
      replicas: 3
      update_config:
        parallelism: 1        # Update 1 at a time
        delay: 10s            # Wait 10s between updates
        failure_action: rollback
        monitor: 60s
      rollback_config:
        parallelism: 1
        delay: 5s

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
// /etc/docker/daemon.json
{
  "userns-remap": "default",
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  },
  "storage-driver": "overlay2",
  "live-restore": true
}

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
# Better volume performance on macOS
volumes:
  - ./src:/app/src:delegated  # Host writes are delayed
  - ./build:/app/build:cached  # Container writes are cached

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
# Windows-compatible paths
volumes:
  - C:/Users/name/app:/app  # Forward slashes work
  # or
  - C:\Users\name\app:/app  # Backslashes need escaping in YAML

Performance Best Practices

Build Performance

# Use BuildKit (faster, better caching)
export DOCKER_BUILDKIT=1

# Use cache mounts
RUN --mount=type=cache,target=/root/.cache/pip \
    pip install -r requirements.txt

# Use bind mounts for dependencies
RUN --mount=type=bind,source=package.json,target=package.json \
    --mount=type=bind,source=package-lock.json,target=package-lock.json \
    --mount=type=cache,target=/root/.npm \
    npm ci

Image Size

  • Use multi-stage builds
  • Choose minimal base images
  • Clean up in the same layer
  • Use .dockerignore
  • Remove build dependencies
# Install and cleanup in one layer
RUN apt-get update && \
    apt-get install -y --no-install-recommends \
    package1 \
    package2 && \
    apt-get clean && \
    rm -rf /var/lib/apt/lists/*

Runtime Performance

# Use exec form (no shell overhead)
CMD ["node", "server.js"]  # Good
# vs
CMD node server.js         # Bad - spawns shell

# Optimize signals
STOPSIGNAL SIGTERM

# Run as non-root (slightly faster, much more secure)
USER appuser

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 Essentials

用于容器管理,图像操作,调试的基本道克命令和工作流程.

运维与云

Find Skills

从开放的代理技能生态系统中发现并安装技能. 使用时:(1)用户问"我如何做X",X可能拥有现有技能,(2)用户说"为X找到技能"或"是否为X有技能",(3)用户问"你能否做X",X是专门能力,(4)用户想扩展代理能力,(5)用户想搜索工具,模板,或工作流程,(6)用户提到他们希望…

运维与云

Microsoft Foundry

构建,部署,评价,优化,微调,管理微软创始代理,模型,资源最终结束. 用法:铸造、azd ai代理、azd 提供/部署、托管代理脚手架/开发/运行/部署/拖放、即时代理创建、创建代理、更新代理、添加代理工具、援引代理、代理.yaml、评估代理、批量活化、连续活化、持续监测、代理C…

运维与云

Azure Deploy

执行已有.azure/部署计划.md和基础设施文件的ALREADY-PREPARED应用程序的Azure部署。 当用户向 CREATE 请求新应用程序时, 请不要使用此技能 。 这种技能运行了 azd上行, azd 部署, trarraform 应用, 和 az 部署命令带有内置…