docker

Name: docker
Author: iuliandita

github.com/iuliandita云与 DevOps1063 次安装今天更新

代码仓库

关于 docker

面向 Docker 和容器工作的技能，帮助团队编写、审查和设计 Dockerfile、Compose 配置及容器流程。内容覆盖生产加固、供应链安全、CI 与运行时迁移，并提供验证清单。

主要功能

01编写与审查 Dockerfile
02配置 Docker Compose 服务栈
03优化镜像大小与构建缓存
04加固容器及合规检查
05镜像签名、SBOM 与漏洞扫描
06Docker、Podman 等运行时迁移

适用场景

01为应用设计多阶段 Dockerfile
02部署开发或生产 Compose 服务栈
03检查容器 PCI-DSS 或 SOC 2 加固
04为镜像构建添加签名与 SBOM

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/iuliandita/skills --skill docker

安装后在 Claude Code 中输入/docker确认已加载。

包含的文件

除 SKILL.md 外，安装时一起下载的参考资料和脚本。

references/

agent-hygiene.md

alternative-runtimes.md

compose-patterns.md

dockerfile-patterns.md

output-contract.md

security-and-compliance.md

target-versions.md

详细介绍

Docker 与容器：生产基础设施

编写、审查并设计 Dockerfile、Compose 堆栈和容器工作流——从单服务开发环境，到包含镜像签名和合规性关卡的多架构生产流水线。目标是打造精简、安全、可复现的镜像，让团队易于维护，并便于 QSA 审计。

目标版本：2026 年 10 月快照。固定 Docker、Compose、BuildKit、containerd、Podman、Buildah 或 runc 的版本前，请先阅读 references/target-versions.md。

此技能涵盖 Dockerfile、Compose、容器加固、供应链、镜像仓库/CI 模式，以及 Docker、Podman、Buildah、Skopeo 和 containerd 之间的运行时迁移。

适用场景

编写或审查 Dockerfile（单阶段或多阶段）
配置 Docker Compose 堆栈（开发、预发布、生产）
优化镜像大小、构建速度或层缓存
加固容器以满足生产环境或合规要求
配置镜像签名、SBOM 生成或漏洞扫描
容器化 AI/ML 工作负载（Model Runner、GPU 直通、模型服务）
从 Docker 迁移到 Podman，或使用 Buildah 构建
针对 PCI-DSS 4.0 或 SOC 2 审查容器安全态势
排查容器网络、卷或构建问题
使用 docker init 为新项目搭建脚手架

不适用场景

Kubernetes 清单、Helm chart、集群架构（使用 kubernetes）
CI/CD 流水线设计（使用 ci-cd）
应用代码安全审计（使用 security-audit）
使用 Terraform 配置基础设施（使用 terraform）

AI 自检

AI 工具经常犯同样的 Docker 错误。返回任何生成的 Dockerfile 或 Compose 文件之前，请按此清单核验：

性能

按从稳定到易变的顺序排列 Dockerfile 层，并在支持 BuildKit 时使用缓存挂载来缓存包管理器。
使用 .dockerignore 缩小构建上下文；意外包含整个单体仓库的构建上下文会显著拖慢构建。
使用多阶段构建和精简的运行时镜像，但在大幅精简工具前，先评估启动和调试需求。

最佳实践

对敏感工作负载固定基础镜像摘要，并跟踪安全更新的重建周期。
以非 root 用户运行，并移除不必要的功能，除非工作负载确实需要它们。
预览清理和删除卷的命令；持久化数据绝不能成为清理时的误删对象。

工作流

复制此检查清单并跟踪进度：

第 1 步：已确定领域
第 2 步：已收集上下文（运行时、环境、基础镜像、机密信息、合规要求）
第 3 步：已编写 Dockerfile、Compose 文件或配置
第 4 步：验证无误（如有任何失败，修复后返回第 3 步）
已通过生产检查清单和 AI 自检

第 1 步：确定领域

根据请求判断：

“编写 Dockerfile” / “将此应用容器化” -> Dockerfile
“设置 docker compose” / “多服务堆栈” -> Compose
“加固此配置” / “使其符合 PCI 标准” / “扫描漏洞” -> 安全
“签署镜像” / “生成 SBOM” / “CI 流水线” -> 镜像仓库与 CI
“使用 Podman” / “无根容器” / “无守护进程构建” -> 运行时
“审查此 Dockerfile/compose” -> 应用生产检查清单 + AI 自检

第 2 步：收集上下文

开始编写前，确定以下信息：

应用类型：语言、框架、构建系统
运行时：Bun、Node.js、Python、Go、Rust、Java——这决定基础镜像和构建模式
环境：开发环境（热重载、调试）与生产环境（精简、加固）
基础镜像：Alpine（体积小，musl）与 Debian-slim（兼容 glibc）与 distroless（无 shell）与 Chainguard（零 CVE）与 scratch（静态二进制文件）
机密信息：如何注入？（环境变量、挂载文件、Docker secrets、保管库）
合规要求：PCI CDE？受监管？需要哪些扫描/签署？
目标镜像仓库：Docker Hub、GHCR、私有镜像仓库，是否兼容 OCI？
AI/ML：GPU 工作负载？模型服务？Docker Model Runner？

第 3 步：构建

遵循下方对应领域的章节。完成前，运行第 4 步、## Production Checklist 和 AI 自检。

第 4 步：验证

如有任何失败，先修复，再返回第 3 步，并从 docker build --check 重新运行验证，直到所有检查通过，且不存在未接受的 HIGH/CRITICAL 发现。报告任何不可用的工具。

# Dockerfile
docker build --check .                # lint without building
docker build -t test-build .          # Use --no-cache only when investigating stale cache or clean-build reproducibility
docker history test-build --format "{{.Size}}\t{{.CreatedBy}}" | head -15

# Compose
docker compose config                 # validate and render
docker compose --dry-run up           # dry-run startup (Compose v5)

# Security (Trivy default; Grype or Docker Scout if the repo already uses them)
if command -v trivy >/dev/null; then
  trivy image --severity HIGH,CRITICAL --exit-code 1 <image>   # use v0.74.0+; never v0.69.4-6
else
  echo "trivy not installed: image scan NOT run; report it as unverified"
fi
syft <image> -o spdx-json             # generate SBOM
cosign verify --key <key> <image>     # verify signature

Dockerfile

阅读 references/dockerfile-patterns.md，了解完整且适用于生产环境的 Dockerfile 模板（Node.js/Bun、Python、Go、Rust、静态网站）和 BuildKit 语法参考。

基础镜像选择

需要 shell 或包管理器：使用精简版 Debian 或 Ubuntu 基础镜像。
需要体积最小的静态运行时：使用 distroless 或 scratch。
需要经过加固的精简用户空间：使用 Chainguard 或其他经过验证的 Wolfi 风格基础镜像。
将构建器与运行时分开；golang、rust 和其他较大的工具链镜像仅用于构建阶段。

语言对应的基础镜像建议和模板详见 references/dockerfile-patterns.md。

关键模式

多阶段构建——任何编译型或转译型语言都必须采用的模式：

# syntax=docker/dockerfile:1
FROM node:22-slim AS build
WORKDIR /app
COPY package.json package-lock.json ./
RUN --mount=type=cache,target=/root/.npm \
    npm ci
COPY . .
RUN npm run build && npm prune --omit=dev

FROM gcr.io/distroless/nodejs22-debian13
WORKDIR /app
COPY --from=build --chown=1001:1001 /app/dist ./dist
COPY --from=build --chown=1001:1001 /app/node_modules ./node_modules
USER 1001
EXPOSE 3000
HEALTHCHECK --interval=30s --timeout=5s --start-period=10s --retries=3 \
  CMD ["/nodejs/bin/node", "-e", "fetch('http://localhost:3000/health').then(r=>r.ok||process.exit(1)).catch(()=>process.exit(1))"]
CMD ["dist/index.js"]

BuildKit 功能（需要 # syntax=docker/dockerfile:1 或 DOCKER_BUILDKIT=1）：

缓存挂载：RUN --mount=type=cache,target=/root/.npm npm ci——在多次构建之间保留包缓存
机密挂载：RUN --mount=type=secret,id=npmrc,target=/root/.npmrc npm ci——机密不会被写入镜像层
Here-doc：无需繁琐地使用反斜杠即可编写多行脚本

RUN <<EOF
set -e
apt-get update
apt-get install -y --no-install-recommends ca-certificates
rm -rf /var/lib/apt/lists/*
EOF

--check 标志：docker build --check . 可在不构建的情况下验证 Dockerfile（试运行式 lint）
SLSA 来源证明：docker build --provenance=true --sbom=true . 会附加证明材料

docker init：生成 Dockerfile、compose.yaml 和 .dockerignore。适合作为起点，但务必检查。

不要编写的内容

在安装依赖项之前执行 COPY . .（每次源代码变更都会使缓存失效）
对本地文件使用 ADD（应使用 COPY——ADD 仅用于自动将 .tar.gz 归档解压到镜像中）
MAINTAINER（已弃用——请使用 LABEL maintainer="..."）
RUN cd /dir && ...（请使用 WORKDIR /dir）
为每个包的安装单独使用 RUN（使用 && 串联）
对任何内容执行 chmod 777
在 ARG 或 ENV 中放置机密
FROM node:latest 或 FROM python（未固定版本）
同时使用 ENTRYPOINT 和 CMD，除非 ENTRYPOINT 是二进制文件，而 CMD 是可覆盖的默认参数（例如，ENTRYPOINT ["/app"] + CMD ["--config", "/etc/app.yaml"]）

Compose

请阅读 references/compose-patterns.md，了解完整的 Compose v5 模板（Web + 数据库、开发环境覆盖、生产环境加固、AI/ML 技术栈）以及网络和卷模式。

Compose v5

不要使用旧的 version: 字段。
预期使用基于 Bake 的构建、watch、试运行验证，以及更新的面向模型的服务配置。
将开发和生产环境的关注点分开；使用覆盖文件仍是合理的默认做法。
将健康检查和依赖项就绪状态视为 Compose 设计的常规组成部分，而非可选项。

关键模式

开发/生产环境分离，使用覆盖文件：

# compose.yaml (base)
services:
  app:
    image: myapp:1.0.0
    healthcheck:
      test: ["CMD-SHELL", "wget -qO /dev/null http://localhost:3000/health || exit 1"]
      interval: 30s
      timeout: 5s
      start_period: 10s
      retries: 3

# compose.override.yaml (dev - auto-loaded)
services:
  app:
    build: .
    volumes:
      - .:/app
      - /app/node_modules
    environment:
      NODE_ENV: development
    ports:
      - "9229:9229"
    command: bun run dev

机密：使用顶层 secrets:，并通过 file: 或 external: true 配置；按照 _FILE 环境变量约定引用（例如，POSTGRES_PASSWORD_FILE: /run/secrets/db_pass）。切勿在 environment: 中硬编码机密。完整的机密配置模板请参阅 references/compose-patterns.md。

由健康状态控制的依赖项：使用带有 condition: service_healthy 的 depends_on:——单独使用 depends_on 只控制顺序，不保证依赖项已就绪。例外情况：无法公开健康检查的依赖项；请在行内注释中说明例外。

Compose 反模式

version: "3.8"——已无效的字段，应移除
在每个服务上设置 container_name（会导致 docker compose up --scale 无法正常工作）
未配置健康检查却设置 restart: always（损坏的容器会无限重启）
在端口映射可行时使用 network_mode: host（改用用户自定义的桥接网络和明确的 ports: 映射）
使用不带 condition: 的 depends_on（只控制顺序，不保证就绪）
在生产环境中通过 volumes: 挂载整个项目目录（泄漏了开发环境模式）
在 Compose 服务上设置 privileged: true，而非在宿主机 LXC 上设置
内联配置 20 个以上的 environment: 条目（请使用 env_file:）

安全

请阅读 references/security-and-compliance.md，了解完整的 PCI-DSS 4.0 容器要求映射、CVE 参考、运行时加固模式以及扫描工具对比。

严重漏洞（2025-2026）

完整的 CVE 表格（涵盖 Docker Desktop、runc、Trivy、Model Runner、BuildKit、Engine、Podman、go-archive）及其影响和修复版本位于 references/security-and-compliance.md；审查版本或回答 CVE 问题时请阅读该文件。

操作项：将 runc 升级至 >= 1.4.0，将 BuildKit 升级至 >= 0.33.1，将 Docker Desktop 升级至 >= 4.71.0（优先使用当前的 4.93.0 快照），将 Docker Engine 升级至 >= 29.8.2，将 Podman 升级至 >= 6.1.3 或 5.8.8，切勿拉取 Trivy v0.69.4/5/6。将所有 CI 工具镜像固定为 SHA256 摘要。

加固后的 Compose 基线

每个生产服务都应从此配置开始，仅放宽必要的限制：

services:
  app:
    image: myapp:1.0.0          # pinned, never :latest
    read_only: true
    security_opt:
      - no-new-privileges:true
    cap_drop:
      - ALL
    cap_add: []                 # add ONLY what's needed (see note below)
    tmpfs:
      - /tmp
    user: "1001:1001"
    healthcheck:
      test: ["CMD-SHELL", "wget -qO /dev/null http://localhost:8080/health || exit 1"]
      interval: 30s
      timeout: 5s
      start_period: 15s
      retries: 3
    deploy:
      resources:
        limits:
          memory: 512M
          cpus: "1.0"
    logging:
      driver: json-file
      options:
        max-size: "10m"
        max-file: "3"

cap_drop: ALL 警告：许多镜像（LSIO、HOTIO、官方 redis/postgres，以及任何使用 gosu/setpriv/su-exec 的镜像）会以 root 身份启动，并在运行时降权。它们至少需要 cap_add: ["SETUID", "SETGID"]，而启动时会对文件执行 chown 的镜像还需要 "CHOWN"。应用一刀切的权限丢弃前，务必阅读镜像的入口点，以确定所需的功能权限。盲目设置 cap_drop: ALL 且 cap_add 为空会导致 CrashLoopBackOff。详细指南请参阅 security-audit 技能中的“No blanket capability drops”规则。

Dockerfile 加固模式请参阅 references/dockerfile-patterns.md（Language Templates 部分）。

供应链安全

使用 cosign（Sigstore）对镜像签名：cosign sign --key cosign.key <image>@<digest>
在构建时生成 SBOM：syft <image> -o spdx-json
部署时验证：cosign verify --key cosign.pub <image>@<digest>
将 CI 工具镜像固定到 SHA256 摘要。 可变标签已被证实是攻击途径（Trivy，2026 年 3 月；tj-actions/reviewdog，2025 年 3 月）。
定期使用 CI 扫描器或注册表端扫描，重新扫描已发布的镜像。
Trivy：新固定版本请使用官方发行版中的 v0.74.0+。v0.69.3 是 2026 年 3 月的回滚版本。v0.69.4-6 含有窃取凭据的恶意软件。如果 2026 年 3 月 19 日至 23 日期间有任何 CI 流水线运行过受感染的 Trivy，请轮换所有密钥。

PCI-DSS 4.0 容器要求（摘要）

PCI-DSS 4.0.1 是唯一有效版本（4.0 已于 2024 年 12 月 31 日退役）。主要的容器专属要求如下：

Req 1：网络分段——使用用户定义的桥接网络；后端服务设置 internal: true；切勿将 CDE 容器暴露在默认桥接网络上
Req 2.2：加固容器——非 root 用户、丢弃功能权限、只读根文件系统、每个容器仅运行一个进程
Req 4：加密传输——Compose 中的 CDE 容器之间使用 TLS（挂载证书、使用启用 TLS 的镜像，或在前端部署终止 TLS 的反向代理）
Req 5.2/5.3：不可变镜像（按摘要部署），使用 Falco 进行运行时检测
Req 6.3：部署前扫描每个镜像的漏洞（Docker Scout、Grype、Trivy v0.74.0+）
Req 6.3.2：每个生产镜像都要有 SBOM
Req 8.6.2：镜像、Compose 文件或环境变量中不得包含硬编码密钥
Req 10：审计日志——将容器标准输出/标准错误写入不可变日志存储
Req 11.5：镜像摘要固定 + Falco = 容器的 FIM

完整映射请参阅 references/security-and-compliance.md。

注册表与 CI

CI 流水线模式

先使用 docker build --check 构建，再使用 buildx 输出来源证明和 SBOM。
部署前进行扫描，按摘要签名，并保留 SBOM 构建产物，即使注册表也存储了 SBOM。
将 CI 侧的工具和操作固定到不可变摘要，而不是可变标签。

Docker Model Runner（AI/ML）

Docker Model Runner（Engine 29.x、Desktop 4.50+）通过兼容 OpenAI/Ollama 的 API 提供 AI 模型服务：

# Compose integration with Model Runner (Compose injects the endpoint; no hardcoded host)
services:
  agent:
    build: .
    models:
      llm:
        endpoint_var: OPENAI_BASE_URL   # default would be LLM_URL (already ends in /v1/)
        model_var: OPENAI_MODEL
models:
  llm:
    model: ai/llama3.2:3B-Q4_K_M

GPU 容器：使用 deploy.resources.reservations.devices，并设置 capabilities: [gpu]。单 GPU 的 shm_size 从 16gb 开始，多 GPU 从 32gb 开始（vLLM 的张量运算需要共享内存）。完整的 AI/ML 技术栈模板请参阅 references/compose-patterns.md。

生产环境检查清单

完整的构建时检查清单（Dockerfile 正确性、Compose 结构、层缓存、密钥、非 root 用户、健康检查、基础镜像固定）请参阅上文的 AI 自检。以下项目仅涵盖部署时和运维方面的补充内容。

部署时新增项

合规性（PCI-DSS 4.0）

参考文件

references/dockerfile-patterns.md - Dockerfile 模板和构建模式
references/compose-patterns.md - Compose 模式和常见堆栈布局
references/security-and-compliance.md - 完整的 2025-2026 CVE 表、Trivy 遭入侵事件的经验教训、扫描和签名、容器加固、合规性指南，以及安全发布公共自定义镜像
references/alternative-runtimes.md - Podman、Buildah、Skopeo 及相关运行时模式
references/target-versions.md - Docker、Compose、BuildKit、containerd、Podman、Buildah 和 runc 的 2026 年 10 月版本快照

输出约定

完整约定请参阅 references/output-contract.md。

Skill 名称： DOCKER
交付物类别： audits
模式： 有条件。调用以分析、审查、审计或改进现有仓库内容时，请遵循 references/output-contract.md 中的报告篇幅和证据规则，并将交付物写入 docs/local/audits/docker/<YYYY-MM-DD>-<slug>.md。调用以回答问题、讲解概念、构建新产物或生成内容时，可自由作答，无需遵循该约定。
严重性等级： P0 | P1 | P2 | P3 | info（参见共享约定；仅用于审计/审查模式）。

规则

将生产环境镜像解析为摘要。 模板标签用于说明镜像系列；它们是可变的，不能保证可复现性。
对编译型／转译型语言使用多阶段构建。 构建工具不应包含在生产环境镜像中。
使用非 root 用户。 每个生产环境容器都必须以非 root 用户运行（使用数字 UID 以兼容 K8s）。
设置有意义的服务健康检查。 对长期运行的服务，使用 Dockerfile、Compose 或编排器探针；对一次性任务，使用退出状态，并记录外部监控要求。
将 CI 工具固定到 SHA256 摘要。 可变标签是供应链攻击的途径（Trivy CVE-2026-33634，2026 年 3 月；tj-actions CVE-2025-30066（上游：reviewdog CVE-2025-30154），2025 年 3 月）。
新固定版本请使用 Trivy v0.74.0+。 v0.69.3 是 2026 年 3 月的回退版本；v0.69.4-6 含有窃取凭据的恶意软件。如果你运行过这些版本，请轮换密钥。
为生产环境容器设置资源限制。 内存和 CPU 限制可防止邻居干扰和 OOM 级联。

支持 Markdown

登录后评论

基本信息

作者: iuliandita
仓库: iuliandita/skills
分类: 云与 DevOps
安装次数: 63
GitHub Stars: 10

报告问题

docker

关于 docker

主要功能

适用场景

安装

包含的文件

详细介绍

Docker 与容器：生产基础设施

适用场景

不适用场景

AI 自检

性能

最佳实践

工作流

第 1 步：确定领域

第 2 步：收集上下文

第 3 步：构建

第 4 步：验证

Dockerfile

基础镜像选择

关键模式

不要编写的内容

Compose

Compose v5

关键模式

Compose 反模式

安全

严重漏洞（2025-2026）

加固后的 Compose 基线

供应链安全

PCI-DSS 4.0 容器要求（摘要）

注册表与 CI

CI 流水线模式

Docker Model Runner（AI/ML）

生产环境检查清单

部署时新增项

合规性（PCI-DSS 4.0）

参考文件

输出约定

相关技能

规则

评论