32d - AI辅助容器化
本文是《AI Agent 实战手册》第 32 章第 4 节。 上一节:32c-AI辅助CI-CD配置 | 下一节:32e-AI辅助监控与事件响应
概述
容器化是现代云原生应用交付的基石,而 AI 正在将容器配置从”手动编写 Dockerfile 和 YAML”推向”自然语言驱动的智能容器化”新范式。2025-2026 年,Docker 推出了 MCP Toolkit 让 Claude Code 可以直接搜索 Docker Hub 镜像并生成完整的 Compose 栈;Snyk 发布了 MCP Server 实现 Agentic 容器安全扫描;ICSE 2026 发表了 DRAFT 框架研究 LLM 自动生成和优化 Dockerfile 的方法论。本节深入覆盖 AI 辅助 Dockerfile 生成与优化(多阶段构建、层优化、安全加固)、docker-compose 多服务编排、Kubernetes manifests 生成(Deployments、Services、Ingress、ConfigMaps、Secrets)、Helm Chart 生成、容器安全扫描等核心主题,提供完整的 Prompt 模板库和实战案例,帮助 DevOps 工程师在 AI 时代高效构建安全、精简、生产就绪的容器化应用。
1. AI 辅助容器化工具全景
1.1 容器化 AI 工具对比
| 工具 | 用途 | 价格 | 适用场景 |
|---|---|---|---|
| GitHub Copilot | IDE 内生成 Dockerfile、docker-compose.yml、K8s YAML 补全 | Individual $10/月;Business $19/月;Enterprise $39/月 | 所有容器化配置的日常编写 |
| Claude Code + Docker MCP Toolkit | 自然语言生成完整 Docker Compose 栈、搜索 Docker Hub 镜像 | Claude Pro $20/月;Max $100/月(含 Claude Code) | 从零生成多服务容器编排 |
| Cursor | AI 辅助 Dockerfile/K8s YAML 编写、上下文感知补全 | Hobby 免费;Pro $20/月;Business $40/月 | 需要项目上下文的容器配置 |
| Docker Scout | 容器镜像漏洞扫描、SBOM 生成、策略评估、修复建议 | Docker Pro $5/月起(含 Scout);Team $9/用户/月;Business $24/用户/月 | 容器镜像安全管理 |
| Snyk Container + MCP Server | Agentic 容器安全扫描、漏洞检测、基础镜像推荐 | Free 版有限扫描;Team $25/月起;Enterprise 定制 | AI 驱动的容器安全工作流 |
| K8sGPT | AI 驱动的 Kubernetes 集群诊断、自然语言问题解释 | 开源免费 | K8s 集群故障排查与优化 |
| kubectl-ai | 自然语言生成 K8s manifests、调试 YAML 配置 | 开源免费(需 LLM API 费用) | 快速生成和调试 K8s 资源 |
| Workik Docker Generator | 在线 AI 生成 Dockerfile 和 docker-compose 配置 | 免费 | 快速原型、学习参考 |
| Workik K8s Generator | 在线 AI 生成 K8s YAML 和 Helm Chart | 免费 | K8s 配置快速生成 |
| OneCompiler Docker Writer | 在线 AI 生成多语言 Dockerfile | 免费 | 学习和快速验证 |
| Trivy | 容器镜像漏洞扫描、IaC 扫描、SBOM 生成 | 开源免费;Aqua 商业版定制价格 | CI/CD 集成的安全扫描 |
| Kube-copilot | AI 辅助 K8s manifest 生成、集群诊断、安全扫描 | 开源免费 | K8s 运维自动化 |
1.2 AI 辅助容器化能力层次模型
┌─────────────────────────────────────────────────────────┐
│ Level 4:自主容器化(Autonomous Containerization) │
│ AI Agent 自主分析项目、生成优化配置、扫描修复安全问题 │
│ 代表:Claude Code + Docker MCP、Snyk MCP Server │
├─────────────────────────────────────────────────────────┤
│ Level 3:智能优化(Intelligent Optimization) │
│ AI 分析现有配置,建议镜像瘦身、层优化、安全加固 │
│ 代表:Docker Scout AI 建议、Snyk Container 修复建议 │
├─────────────────────────────────────────────────────────┤
│ Level 2:对话式生成(Conversational Generation) │
│ 通过自然语言对话生成完整容器配置 │
│ 代表:ChatGPT/Claude 对话、K8sGPT、kubectl-ai │
├─────────────────────────────────────────────────────────┤
│ Level 1:代码补全(Code Completion) │
│ 在 IDE 中自动补全 Dockerfile/YAML 配置片段 │
│ 代表:Copilot 内联建议、Cursor Tab 补全 │
├─────────────────────────────────────────────────────────┤
│ Level 0:模板参考(Template Reference) │
│ 使用预定义模板和文档手动编写 │
│ 代表:Docker 官方示例、Helm Hub 模板 │
└─────────────────────────────────────────────────────────┘1.3 AI 辅助容器化工作流全景
┌──────────────────────────────────────────────────────────────────┐
│ AI 辅助容器化完整工作流 │
├──────────────────────────────────────────────────────────────────┤
│ │
│ ① 项目分析 ② Dockerfile 生成 ③ 镜像优化 │
│ ┌──────────┐ ┌──────────────┐ ┌──────────────┐ │
│ │ AI 分析 │──────▶│ 多阶段构建 │──────▶│ 层合并/瘦身 │ │
│ │ 项目结构 │ │ 依赖安装 │ │ 基础镜像选择 │ │
│ │ 依赖文件 │ │ 安全加固 │ │ 缓存优化 │ │
│ └──────────┘ └──────────────┘ └──────────────┘ │
│ │ │ │
│ ▼ ▼ │
│ ④ Compose 编排 ⑤ K8s Manifests ⑥ 安全扫描 │
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │
│ │ 多服务定义 │ │ Deployment │ │ Docker Scout │ │
│ │ 网络/卷配置 │ │ Service │ │ Snyk/Trivy │ │
│ │ 健康检查 │ │ Ingress │ │ 漏洞修复 │ │
│ │ 环境变量 │ │ Helm Chart │ │ 策略合规 │ │
│ └──────────────┘ └──────────────┘ └──────────────┘ │
│ │
└──────────────────────────────────────────────────────────────────┘2. AI 辅助 Dockerfile 生成与优化
2.1 基础 Dockerfile 生成
AI 可以根据项目类型和技术栈快速生成符合最佳实践的 Dockerfile。关键在于提供足够的上下文信息。
提示词模板:基础 Dockerfile 生成
请为我的 [语言/框架] 项目生成一个生产级 Dockerfile,要求:
项目信息:
- 语言/框架:[如 Node.js 20 + Express / Python 3.12 + FastAPI / Go 1.22 / Rust 1.78]
- 包管理器:[如 npm / pnpm / pip / cargo]
- 构建命令:[如 npm run build / go build -o app]
- 启动命令:[如 node dist/index.js / uvicorn main:app]
- 暴露端口:[如 3000 / 8000 / 8080]
- 需要的系统依赖:[如 无 / ffmpeg / imagemagick]
优化要求:
1. 使用多阶段构建,分离构建环境和运行环境
2. 选择最小基础镜像(alpine 或 distroless)
3. 优化层缓存(先复制依赖文件,再复制源码)
4. 以非 root 用户运行
5. 包含 HEALTHCHECK 指令
6. 添加 .dockerignore 建议
7. 添加详细注释说明每一步的目的
请同时输出:
- 完整的 Dockerfile
- 推荐的 .dockerignore 文件
- 构建和运行命令
- 预估镜像大小示例:Node.js 多阶段构建 Dockerfile
以下是 AI 根据上述模板生成的典型 Node.js 生产级 Dockerfile:
# ============================================
# 阶段 1:依赖安装(Dependencies)
# 使用完整 Node 镜像安装所有依赖
# ============================================
FROM node:20-alpine AS deps
# 安全加固:使用非 root 用户
RUN addgroup -g 1001 -S appgroup && \
adduser -S appuser -u 1001 -G appgroup
WORKDIR /app
# 优化层缓存:先复制包管理文件
# 只有 package.json 或 lock 文件变化时才重新安装依赖
COPY package.json package-lock.json ./
# 仅安装生产依赖,减小最终镜像体积
RUN npm ci --only=production && \
# 清理 npm 缓存
npm cache clean --force
# ============================================
# 阶段 2:构建(Builder)
# 编译 TypeScript / 打包前端资源
# ============================================
FROM node:20-alpine AS builder
WORKDIR /app
# 复制所有依赖(包括 devDependencies)
COPY package.json package-lock.json ./
RUN npm ci
# 复制源码并构建
COPY . .
RUN npm run build
# ============================================
# 阶段 3:运行(Runner)
# 最小化生产镜像
# ============================================
FROM node:20-alpine AS runner
# 安全元数据
LABEL maintainer="team@example.com"
LABEL org.opencontainers.image.source="https://github.com/org/repo"
# 安全加固:创建非 root 用户
RUN addgroup -g 1001 -S appgroup && \
adduser -S appuser -u 1001 -G appgroup
WORKDIR /app
# 仅复制生产依赖和构建产物
COPY --from=deps --chown=appuser:appgroup /app/node_modules ./node_modules
COPY --from=builder --chown=appuser:appgroup /app/dist ./dist
COPY --from=builder --chown=appuser:appgroup /app/package.json ./
# 环境变量
ENV NODE_ENV=production
ENV PORT=3000
# 暴露端口
EXPOSE 3000
# 切换到非 root 用户
USER appuser
# 健康检查
HEALTHCHECK --interval=30s --timeout=3s --start-period=10s --retries=3 \
CMD wget --no-verbose --tries=1 --spider http://localhost:3000/health || exit 1
# 使用 tini 作为 PID 1 进程,正确处理信号
RUN apk add --no-cache tini
ENTRYPOINT ["/sbin/tini", "--"]
# 启动应用
CMD ["node", "dist/index.js"]推荐的 .dockerignore
# 版本控制
.git
.gitignore
# 依赖目录(容器内重新安装)
node_modules
# 构建产物(容器内重新构建)
dist
build
# 开发配置
.env
.env.local
.env.*.local
# IDE 配置
.vscode
.idea
*.swp
*.swo
# 测试和文档
__tests__
*.test.ts
*.spec.ts
coverage
docs
README.md
LICENSE
# Docker 相关
Dockerfile*
docker-compose*
.dockerignore
# CI/CD
.github
.gitlab-ci.yml2.2 多阶段构建深度优化
多阶段构建是 Dockerfile 优化的核心技术。AI 可以根据不同语言的特点生成最优的多阶段构建方案。
提示词模板:多阶段构建优化
请优化以下 Dockerfile,使用多阶段构建:
当前 Dockerfile:
[粘贴现有 Dockerfile]
优化目标:
1. 最终镜像只包含运行时必需的文件
2. 构建工具、源码、测试文件不进入最终镜像
3. 利用 BuildKit 缓存加速重复构建
4. 最终镜像大小目标:< [目标大小,如 100MB]
请输出:
- 优化后的多阶段 Dockerfile
- 每个阶段的职责说明
- 优化前后的镜像大小对比估算
- BuildKit 缓存挂载的使用建议示例:Python FastAPI 多阶段构建
# ============================================
# 阶段 1:构建依赖(Builder)
# ============================================
FROM python:3.12-slim AS builder
WORKDIR /app
# 安装构建工具(编译 C 扩展需要)
RUN apt-get update && \
apt-get install -y --no-install-recommends gcc libpq-dev && \
rm -rf /var/lib/apt/lists/*
# 使用 BuildKit 缓存加速 pip 安装
COPY requirements.txt .
RUN --mount=type=cache,target=/root/.cache/pip \
pip install --prefix=/install -r requirements.txt
# ============================================
# 阶段 2:运行(Runner)
# ============================================
FROM python:3.12-slim AS runner
# 安全加固
RUN groupadd -r appgroup && \
useradd -r -g appgroup -d /app -s /sbin/nologin appuser
WORKDIR /app
# 仅安装运行时系统依赖
RUN apt-get update && \
apt-get install -y --no-install-recommends libpq5 curl && \
rm -rf /var/lib/apt/lists/*
# 从构建阶段复制已安装的 Python 包
COPY --from=builder /install /usr/local
# 复制应用代码
COPY --chown=appuser:appgroup . .
ENV PYTHONUNBUFFERED=1
ENV PYTHONDONTWRITEBYTECODE=1
EXPOSE 8000
USER appuser
HEALTHCHECK --interval=30s --timeout=3s --start-period=15s --retries=3 \
CMD curl -f http://localhost:8000/health || exit 1
CMD ["uvicorn", "app.main:app", "--host", "0.0.0.0", "--port", "8000"]示例:Go 应用极致瘦身(使用 scratch)
# ============================================
# 阶段 1:构建
# ============================================
FROM golang:1.22-alpine AS builder
WORKDIR /app
# 利用 Go 模块缓存
COPY go.mod go.sum ./
RUN go mod download
COPY . .
# 静态编译,禁用 CGO,生成独立二进制
RUN CGO_ENABLED=0 GOOS=linux GOARCH=amd64 \
go build -ldflags="-w -s" -o /app/server ./cmd/server
# ============================================
# 阶段 2:运行(scratch = 空镜像)
# ============================================
FROM scratch
# 复制 CA 证书(HTTPS 请求需要)
COPY --from=builder /etc/ssl/certs/ca-certificates.crt /etc/ssl/certs/
# 复制时区数据
COPY --from=builder /usr/share/zoneinfo /usr/share/zoneinfo
# 复制二进制
COPY --from=builder /app/server /server
# 非 root 用户(scratch 中通过 UID 指定)
USER 65534:65534
EXPOSE 8080
ENTRYPOINT ["/server"]镜像大小对比:
- Go + Ubuntu 基础镜像:~800MB
- Go + Alpine:~30MB
- Go + scratch(静态编译):~8-15MB
示例:Rust 应用多阶段构建
# ============================================
# 阶段 1:构建
# ============================================
FROM rust:1.78-slim AS builder
WORKDIR /app
# 利用 cargo 缓存:先编译依赖
COPY Cargo.toml Cargo.lock ./
RUN mkdir src && \
echo "fn main() {}" > src/main.rs && \
cargo build --release && \
rm -rf src
# 复制实际源码并重新编译
COPY src ./src
RUN touch src/main.rs && \
cargo build --release
# ============================================
# 阶段 2:运行
# ============================================
FROM debian:bookworm-slim AS runner
RUN apt-get update && \
apt-get install -y --no-install-recommends ca-certificates && \
rm -rf /var/lib/apt/lists/* && \
groupadd -r appgroup && \
useradd -r -g appgroup appuser
COPY --from=builder /app/target/release/myapp /usr/local/bin/myapp
USER appuser
EXPOSE 8080
HEALTHCHECK --interval=30s --timeout=3s \
CMD ["/usr/local/bin/myapp", "health"]
CMD ["myapp"]2.3 Dockerfile 层优化策略
AI 可以分析现有 Dockerfile 并建议层优化策略,减少镜像大小和构建时间。
提示词模板:Dockerfile 层优化分析
请分析以下 Dockerfile 的层结构,找出优化机会:
[粘贴 Dockerfile]
请从以下维度分析:
1. 层缓存效率:哪些层会频繁失效?如何调整顺序?
2. 层合并机会:哪些 RUN 指令可以合并?
3. 不必要的文件:哪些文件不应该进入镜像?
4. 基础镜像选择:当前基础镜像是否最优?
5. BuildKit 特性:是否可以使用缓存挂载、秘密挂载等?
请输出优化建议和修改后的 Dockerfile。层优化核心原则
| 原则 | 说明 | 示例 |
|---|---|---|
| 依赖文件优先 | 先复制 lock 文件,再复制源码 | COPY package-lock.json . → RUN npm ci → COPY . . |
| 合并 RUN 指令 | 减少层数,清理临时文件 | RUN apt-get update && apt-get install -y pkg && rm -rf /var/lib/apt/lists/* |
| 使用 .dockerignore | 排除不需要的文件 | 排除 .git、node_modules、__pycache__ |
| 固定版本号 | 确保构建可重复 | FROM node:20.11.1-alpine 而非 FROM node:latest |
| BuildKit 缓存 | 使用 --mount=type=cache | RUN --mount=type=cache,target=/root/.cache/pip pip install -r requirements.txt |
| 最小基础镜像 | 选择 alpine/slim/distroless | python:3.12-slim 而非 python:3.12 |
| 多阶段清理 | 构建阶段的工具不进入运行阶段 | 构建阶段安装 gcc,运行阶段不需要 |
BuildKit 高级缓存示例
# syntax=docker/dockerfile:1.7
# 启用 BuildKit 缓存挂载
FROM node:20-alpine AS builder
WORKDIR /app
COPY package.json package-lock.json ./
# npm 缓存挂载:跨构建复用下载的包
RUN --mount=type=cache,target=/root/.npm \
npm ci
COPY . .
RUN npm run build
# 使用秘密挂载:安全传递构建时凭证
FROM node:20-alpine AS private-deps
WORKDIR /app
COPY package.json ./
# 秘密不会写入镜像层
RUN --mount=type=secret,id=npmrc,target=/root/.npmrc \
npm install2.4 安全加固最佳实践
提示词模板:Dockerfile 安全审查
请对以下 Dockerfile 进行安全审查:
[粘贴 Dockerfile]
请检查以下安全维度:
1. 是否以 root 用户运行?
2. 基础镜像是否有已知漏洞?推荐替代镜像
3. 是否泄露了构建秘密(API key、token)?
4. 是否安装了不必要的包?
5. 是否固定了基础镜像版本(避免 latest)?
6. 是否有 HEALTHCHECK?
7. 文件权限是否过于宽松?
8. 是否使用了 COPY 而非 ADD?
9. 是否正确处理了 PID 1 信号?
10. 是否有不安全的网络暴露?
请输出:
- 安全问题清单(按严重程度排序)
- 每个问题的修复建议
- 修复后的 Dockerfile安全加固检查清单
| 检查项 | 风险等级 | 说明 |
|---|---|---|
| 非 root 用户运行 | 🔴 高 | 使用 USER 指令切换到非特权用户 |
| 固定基础镜像版本 | 🔴 高 | 使用 node:20.11.1-alpine 而非 node:latest |
| 无秘密泄露 | 🔴 高 | 不在 Dockerfile 中硬编码密钥,使用 --mount=type=secret |
| 最小基础镜像 | 🟡 中 | 使用 alpine/slim/distroless 减少攻击面 |
| COPY 替代 ADD | 🟡 中 | ADD 会自动解压和支持 URL,增加攻击面 |
| 清理包管理器缓存 | 🟡 中 | rm -rf /var/lib/apt/lists/* |
| 只读文件系统 | 🟡 中 | 运行时使用 --read-only 标志 |
| HEALTHCHECK 指令 | 🟢 低 | 确保容器健康状态可监控 |
| 信号处理(tini) | 🟢 低 | 使用 tini 或 dumb-init 作为 PID 1 |
| OCI 标签 | 🟢 低 | 添加 LABEL 元数据便于追踪 |
安全加固示例:非 root + 只读 + 最小权限
FROM node:20-alpine AS runner
# 创建专用用户和组
RUN addgroup -g 1001 -S appgroup && \
adduser -S appuser -u 1001 -G appgroup && \
# 创建应用需要的可写目录
mkdir -p /app/tmp /app/logs && \
chown -R appuser:appgroup /app
WORKDIR /app
COPY --from=builder --chown=appuser:appgroup /app/dist ./dist
COPY --from=deps --chown=appuser:appgroup /app/node_modules ./node_modules
# 移除不必要的 SUID/SGID 位
RUN find / -perm /6000 -type f -exec chmod a-s {} + 2>/dev/null || true
USER appuser
# 运行时建议使用:
# docker run --read-only --tmpfs /tmp --cap-drop ALL myapp
CMD ["node", "dist/index.js"]3. AI 辅助 Docker Compose 多服务编排
3.1 Docker MCP Toolkit + Claude Code 工作流
2025 年 Docker 官方推出了 MCP Toolkit,让 Claude Code 可以直接搜索 Docker Hub 镜像并生成完整的 Docker Compose 栈。这是目前最强大的 AI 辅助容器编排方案。
设置步骤
- 安装 Docker Desktop(4.40+ 版本,内置 MCP Toolkit)
- 启用 MCP Toolkit:Docker Desktop → Settings → MCP Toolkit → Enable
- 配置 Claude Code:
// ~/.claude/settings.json 或项目 .mcp.json
{
"mcpServers": {
"docker": {
"command": "docker",
"args": ["mcp", "gateway", "run"],
"env": {}
}
}
}- 使用自然语言生成 Compose 栈:
@docker 请为我的全栈应用生成 Docker Compose 配置:
- Next.js 前端(端口 3000)
- FastAPI 后端(端口 8000)
- PostgreSQL 数据库
- Redis 缓存
- Nginx 反向代理
要求:
- 使用最新稳定版镜像
- 配置健康检查
- 设置服务依赖关系
- 使用命名卷持久化数据
- 配置自定义网络Claude Code 会通过 Docker MCP Toolkit 搜索 Docker Hub 上的最新镜像版本,并生成完整的 Compose 配置。
3.2 Docker Compose 生成提示词模板
提示词模板:完整 Compose 栈生成
请为以下多服务架构生成生产级 docker-compose.yml:
服务架构:
- [服务1]:[描述,如 "Next.js 14 前端,需要构建"]
- [服务2]:[描述,如 "Node.js Express API,连接数据库"]
- [服务3]:[描述,如 "PostgreSQL 16 数据库"]
- [服务4]:[描述,如 "Redis 7 缓存"]
- [服务5]:[描述,如 "Nginx 反向代理,SSL 终止"]
要求:
1. 每个服务配置健康检查(healthcheck)
2. 使用 depends_on + condition: service_healthy 确保启动顺序
3. 配置资源限制(CPU、内存)
4. 使用命名卷持久化数据库和缓存数据
5. 配置自定义桥接网络,隔离前后端
6. 环境变量使用 .env 文件
7. 包含开发和生产两套配置(override 模式)
8. 日志配置(json-file driver,限制大小和数量)
9. 重启策略(unless-stopped)
10. 安全配置(非 root、只读文件系统等)
请同时输出:
- docker-compose.yml(生产配置)
- docker-compose.override.yml(开发覆盖)
- .env.example(环境变量模板)
- 启动和管理命令示例:全栈应用 Docker Compose
# docker-compose.yml - 生产配置
version: "3.9"
services:
# ============================================
# Nginx 反向代理
# ============================================
nginx:
image: nginx:1.27-alpine
container_name: app-nginx
restart: unless-stopped
ports:
- "${NGINX_PORT:-80}:80"
- "${NGINX_SSL_PORT:-443}:443"
volumes:
- ./nginx/nginx.conf:/etc/nginx/nginx.conf:ro
- ./nginx/conf.d:/etc/nginx/conf.d:ro
- ssl-certs:/etc/nginx/ssl:ro
networks:
- frontend
depends_on:
frontend:
condition: service_healthy
backend:
condition: service_healthy
healthcheck:
test: ["CMD", "nginx", "-t"]
interval: 30s
timeout: 5s
retries: 3
deploy:
resources:
limits:
cpus: "0.5"
memory: 256M
logging:
driver: json-file
options:
max-size: "10m"
max-file: "3"
# ============================================
# Next.js 前端
# ============================================
frontend:
build:
context: ./frontend
dockerfile: Dockerfile
target: runner
container_name: app-frontend
restart: unless-stopped
environment:
- NODE_ENV=production
- NEXT_PUBLIC_API_URL=${API_URL:-http://backend:8000}
networks:
- frontend
healthcheck:
test: ["CMD", "wget", "--no-verbose", "--tries=1", "--spider", "http://localhost:3000/api/health"]
interval: 30s
timeout: 5s
start_period: 30s
retries: 3
deploy:
resources:
limits:
cpus: "1.0"
memory: 512M
logging:
driver: json-file
options:
max-size: "10m"
max-file: "3"
# ============================================
# FastAPI 后端
# ============================================
backend:
build:
context: ./backend
dockerfile: Dockerfile
target: runner
container_name: app-backend
restart: unless-stopped
environment:
- DATABASE_URL=postgresql://${DB_USER}:${DB_PASSWORD}@postgres:5432/${DB_NAME}
- REDIS_URL=redis://redis:6379/0
- SECRET_KEY=${SECRET_KEY}
- CORS_ORIGINS=${CORS_ORIGINS:-http://localhost:3000}
networks:
- frontend
- backend
depends_on:
postgres:
condition: service_healthy
redis:
condition: service_healthy
healthcheck:
test: ["CMD", "curl", "-f", "http://localhost:8000/health"]
interval: 30s
timeout: 5s
start_period: 15s
retries: 3
deploy:
resources:
limits:
cpus: "1.0"
memory: 1G
logging:
driver: json-file
options:
max-size: "10m"
max-file: "5"
# ============================================
# PostgreSQL 数据库
# ============================================
postgres:
image: postgres:16-alpine
container_name: app-postgres
restart: unless-stopped
environment:
- POSTGRES_USER=${DB_USER}
- POSTGRES_PASSWORD=${DB_PASSWORD}
- POSTGRES_DB=${DB_NAME}
- PGDATA=/var/lib/postgresql/data/pgdata
volumes:
- postgres-data:/var/lib/postgresql/data
- ./scripts/init-db.sql:/docker-entrypoint-initdb.d/init.sql:ro
networks:
- backend
healthcheck:
test: ["CMD-SHELL", "pg_isready -U ${DB_USER} -d ${DB_NAME}"]
interval: 10s
timeout: 5s
start_period: 30s
retries: 5
deploy:
resources:
limits:
cpus: "1.0"
memory: 1G
logging:
driver: json-file
options:
max-size: "10m"
max-file: "3"
# ============================================
# Redis 缓存
# ============================================
redis:
image: redis:7-alpine
container_name: app-redis
restart: unless-stopped
command: >
redis-server
--maxmemory 256mb
--maxmemory-policy allkeys-lru
--appendonly yes
--requirepass ${REDIS_PASSWORD}
volumes:
- redis-data:/data
networks:
- backend
healthcheck:
test: ["CMD", "redis-cli", "-a", "${REDIS_PASSWORD}", "ping"]
interval: 10s
timeout: 3s
retries: 3
deploy:
resources:
limits:
cpus: "0.5"
memory: 512M
logging:
driver: json-file
options:
max-size: "5m"
max-file: "3"
# ============================================
# 网络配置
# ============================================
networks:
frontend:
driver: bridge
name: app-frontend
backend:
driver: bridge
name: app-backend
internal: true # 后端网络不暴露到外部
# ============================================
# 持久化卷
# ============================================
volumes:
postgres-data:
name: app-postgres-data
redis-data:
name: app-redis-data
ssl-certs:
name: app-ssl-certs开发覆盖配置
# docker-compose.override.yml - 开发环境覆盖
version: "3.9"
services:
frontend:
build:
target: deps # 使用开发阶段
command: npm run dev
volumes:
- ./frontend/src:/app/src # 热重载
- ./frontend/public:/app/public
environment:
- NODE_ENV=development
ports:
- "3000:3000" # 直接暴露(跳过 nginx)
backend:
build:
target: builder
command: uvicorn app.main:app --host 0.0.0.0 --port 8000 --reload
volumes:
- ./backend/app:/app/app # 热重载
environment:
- DEBUG=true
ports:
- "8000:8000" # 直接暴露
postgres:
ports:
- "5432:5432" # 开发时暴露数据库端口
redis:
ports:
- "6379:6379" # 开发时暴露 Redis 端口
# 开发工具:数据库管理
pgadmin:
image: dpage/pgadmin4:latest
container_name: app-pgadmin
environment:
- PGADMIN_DEFAULT_EMAIL=${PGADMIN_EMAIL:-admin@example.com}
- PGADMIN_DEFAULT_PASSWORD=${PGADMIN_PASSWORD:-admin}
ports:
- "5050:80"
networks:
- backend
depends_on:
- postgres环境变量模板
# .env.example
# 复制为 .env 并填写实际值
# 数据库
DB_USER=appuser
DB_PASSWORD=change_me_in_production
DB_NAME=appdb
# Redis
REDIS_PASSWORD=change_me_in_production
# 应用
SECRET_KEY=generate_a_random_secret_key
CORS_ORIGINS=http://localhost:3000
API_URL=http://localhost:8000
# Nginx
NGINX_PORT=80
NGINX_SSL_PORT=443
# 开发工具
PGADMIN_EMAIL=admin@example.com
PGADMIN_PASSWORD=admin3.3 Compose 高级模式
提示词模板:微服务 Compose 编排
请为以下微服务架构生成 Docker Compose 配置:
微服务列表:
- API Gateway(Kong/Traefik)
- User Service(Node.js)
- Order Service(Python)
- Payment Service(Go)
- Notification Service(Node.js)
- Message Queue(RabbitMQ)
- 服务发现(Consul)
- 分布式追踪(Jaeger)
要求:
1. 每个微服务独立构建和部署
2. 服务间通过消息队列异步通信
3. API Gateway 统一入口
4. 配置服务发现和健康检查
5. 集成分布式追踪
6. 支持水平扩展(replicas)
7. 配置日志聚合Compose Profiles 按需启动
# 使用 profiles 按需启动服务组
services:
# 核心服务(始终启动)
backend:
image: myapp-backend:latest
# ... 配置 ...
postgres:
image: postgres:16-alpine
# ... 配置 ...
# 监控服务(按需启动)
prometheus:
image: prom/prometheus:latest
profiles: ["monitoring"]
# ... 配置 ...
grafana:
image: grafana/grafana:latest
profiles: ["monitoring"]
# ... 配置 ...
# 调试服务(按需启动)
pgadmin:
image: dpage/pgadmin4:latest
profiles: ["debug"]
# ... 配置 ...
mailhog:
image: mailhog/mailhog:latest
profiles: ["debug"]
# ... 配置 ...# 启动核心服务
docker compose up -d
# 启动核心 + 监控
docker compose --profile monitoring up -d
# 启动全部(核心 + 监控 + 调试)
docker compose --profile monitoring --profile debug up -d4. AI 辅助 Kubernetes Manifests 生成
4.1 K8s Manifest 生成工具
| 工具 | 方式 | 优势 | 适用场景 |
|---|---|---|---|
| kubectl-ai | CLI 插件,自然语言→YAML | 直接在终端生成,支持多种 LLM | 快速生成单个资源 |
| K8sGPT | CLI 工具,集群诊断+建议 | 分析现有集群问题,自然语言解释 | 故障排查和优化 |
| Copilot/Cursor | IDE 内补全 | 项目上下文感知,实时补全 | 日常 YAML 编写 |
| Claude/GPT 对话 | 对话式生成 | 可以生成复杂的多资源配置 | 完整应用部署方案 |
| Workik K8s Generator | 在线工具 | 免费,快速原型 | 学习和验证 |
| Kube-copilot | CLI 工具 | 集成 kubectl 和 trivy | K8s 运维自动化 |
4.2 核心 K8s 资源生成
提示词模板:完整 K8s 应用部署
请为以下应用生成完整的 Kubernetes 部署配置:
应用信息:
- 名称:[应用名]
- 镜像:[镜像地址:标签]
- 副本数:[如 3]
- 端口:[如 8080]
- 资源需求:CPU [如 100m-500m],内存 [如 128Mi-512Mi]
- 环境变量:[列出关键环境变量]
- 需要持久化存储:[是/否,如果是,说明路径和大小]
- 需要外部访问:[是/否,域名是什么]
- 需要 TLS:[是/否]
请生成以下资源:
1. Namespace
2. Deployment(含就绪探针、存活探针、启动探针)
3. Service(ClusterIP)
4. Ingress(如需外部访问)
5. ConfigMap(非敏感配置)
6. Secret(敏感配置)
7. HorizontalPodAutoscaler
8. PodDisruptionBudget
9. NetworkPolicy
10. ServiceAccount + RBAC(最小权限)
要求:
- 遵循 K8s 最佳实践
- 添加适当的标签和注解
- 配置资源请求和限制
- 使用 Kustomize 友好的结构
- 添加详细注释示例:完整的 K8s 应用部署
Namespace + ServiceAccount
# namespace.yaml
apiVersion: v1
kind: Namespace
metadata:
name: myapp
labels:
app.kubernetes.io/name: myapp
app.kubernetes.io/part-of: myapp-platform
---
# serviceaccount.yaml
apiVersion: v1
kind: ServiceAccount
metadata:
name: myapp-sa
namespace: myapp
labels:
app.kubernetes.io/name: myapp
app.kubernetes.io/component: backend
automountServiceAccountToken: false # 安全:默认不挂载 tokenConfigMap + Secret
# configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
name: myapp-config
namespace: myapp
labels:
app.kubernetes.io/name: myapp
data:
# 非敏感配置
APP_ENV: "production"
LOG_LEVEL: "info"
CORS_ORIGINS: "https://myapp.example.com"
CACHE_TTL: "3600"
---
# secret.yaml
apiVersion: v1
kind: Secret
metadata:
name: myapp-secrets
namespace: myapp
labels:
app.kubernetes.io/name: myapp
type: Opaque
stringData:
# 敏感配置(生产环境建议使用 External Secrets Operator)
DATABASE_URL: "postgresql://user:password@postgres:5432/myapp"
REDIS_URL: "redis://:password@redis:6379/0"
JWT_SECRET: "your-jwt-secret-here"Deployment
# deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: myapp-backend
namespace: myapp
labels:
app.kubernetes.io/name: myapp
app.kubernetes.io/component: backend
app.kubernetes.io/version: "1.0.0"
spec:
replicas: 3
revisionHistoryLimit: 5
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 1
maxUnavailable: 0 # 零停机部署
selector:
matchLabels:
app.kubernetes.io/name: myapp
app.kubernetes.io/component: backend
template:
metadata:
labels:
app.kubernetes.io/name: myapp
app.kubernetes.io/component: backend
app.kubernetes.io/version: "1.0.0"
annotations:
# 配置变更时自动重启 Pod
checksum/config: "{{ include (print $.Template.BasePath \"/configmap.yaml\") . | sha256sum }}"
spec:
serviceAccountName: myapp-sa
automountServiceAccountToken: false
# 安全上下文
securityContext:
runAsNonRoot: true
runAsUser: 1001
runAsGroup: 1001
fsGroup: 1001
seccompProfile:
type: RuntimeDefault
# 优雅终止
terminationGracePeriodSeconds: 30
# 反亲和性:分散到不同节点
affinity:
podAntiAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 100
podAffinityTerm:
labelSelector:
matchExpressions:
- key: app.kubernetes.io/name
operator: In
values: ["myapp"]
topologyKey: kubernetes.io/hostname
containers:
- name: backend
image: registry.example.com/myapp-backend:1.0.0
imagePullPolicy: IfNotPresent
ports:
- name: http
containerPort: 8080
protocol: TCP
# 环境变量
envFrom:
- configMapRef:
name: myapp-config
- secretRef:
name: myapp-secrets
# 资源请求和限制
resources:
requests:
cpu: 100m
memory: 128Mi
limits:
cpu: 500m
memory: 512Mi
# 启动探针:应用启动可能较慢
startupProbe:
httpGet:
path: /health
port: http
initialDelaySeconds: 5
periodSeconds: 5
failureThreshold: 30 # 最多等待 150 秒
# 就绪探针:是否可以接收流量
readinessProbe:
httpGet:
path: /health/ready
port: http
periodSeconds: 10
timeoutSeconds: 3
failureThreshold: 3
# 存活探针:是否需要重启
livenessProbe:
httpGet:
path: /health/live
port: http
periodSeconds: 15
timeoutSeconds: 3
failureThreshold: 3
# 容器安全上下文
securityContext:
allowPrivilegeEscalation: false
readOnlyRootFilesystem: true
capabilities:
drop: ["ALL"]
# 临时可写目录
volumeMounts:
- name: tmp
mountPath: /tmp
- name: app-logs
mountPath: /app/logs
volumes:
- name: tmp
emptyDir:
sizeLimit: 100Mi
- name: app-logs
emptyDir:
sizeLimit: 500MiService + Ingress
# service.yaml
apiVersion: v1
kind: Service
metadata:
name: myapp-backend
namespace: myapp
labels:
app.kubernetes.io/name: myapp
app.kubernetes.io/component: backend
spec:
type: ClusterIP
ports:
- name: http
port: 80
targetPort: http
protocol: TCP
selector:
app.kubernetes.io/name: myapp
app.kubernetes.io/component: backend
---
# ingress.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: myapp-ingress
namespace: myapp
labels:
app.kubernetes.io/name: myapp
annotations:
# Nginx Ingress Controller 注解
nginx.ingress.kubernetes.io/ssl-redirect: "true"
nginx.ingress.kubernetes.io/force-ssl-redirect: "true"
nginx.ingress.kubernetes.io/proxy-body-size: "10m"
nginx.ingress.kubernetes.io/rate-limit: "100"
nginx.ingress.kubernetes.io/rate-limit-window: "1m"
# cert-manager 自动 TLS
cert-manager.io/cluster-issuer: "letsencrypt-prod"
spec:
ingressClassName: nginx
tls:
- hosts:
- api.myapp.example.com
secretName: myapp-tls
rules:
- host: api.myapp.example.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: myapp-backend
port:
name: httpHPA + PDB
# hpa.yaml
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: myapp-backend-hpa
namespace: myapp
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: myapp-backend
minReplicas: 3
maxReplicas: 10
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 70
- type: Resource
resource:
name: memory
target:
type: Utilization
averageUtilization: 80
behavior:
scaleUp:
stabilizationWindowSeconds: 60
policies:
- type: Pods
value: 2
periodSeconds: 60
scaleDown:
stabilizationWindowSeconds: 300
policies:
- type: Pods
value: 1
periodSeconds: 120
---
# pdb.yaml
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
name: myapp-backend-pdb
namespace: myapp
spec:
minAvailable: 2 # 至少保持 2 个 Pod 可用
selector:
matchLabels:
app.kubernetes.io/name: myapp
app.kubernetes.io/component: backendNetworkPolicy
# networkpolicy.yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: myapp-backend-netpol
namespace: myapp
spec:
podSelector:
matchLabels:
app.kubernetes.io/name: myapp
app.kubernetes.io/component: backend
policyTypes:
- Ingress
- Egress
ingress:
# 只允许来自 Ingress Controller 的流量
- from:
- namespaceSelector:
matchLabels:
kubernetes.io/metadata.name: ingress-nginx
ports:
- protocol: TCP
port: 8080
egress:
# 允许访问数据库
- to:
- podSelector:
matchLabels:
app.kubernetes.io/component: database
ports:
- protocol: TCP
port: 5432
# 允许访问 Redis
- to:
- podSelector:
matchLabels:
app.kubernetes.io/component: cache
ports:
- protocol: TCP
port: 6379
# 允许 DNS 查询
- to:
- namespaceSelector: {}
ports:
- protocol: UDP
port: 53
- protocol: TCP
port: 534.3 kubectl-ai 实战
kubectl-ai 是一个 kubectl 插件,可以用自然语言生成 K8s manifests。
安装和配置
# 安装 kubectl-ai
# macOS
brew install kubectl-ai
# 或使用 Go 安装
go install github.com/sozercan/kubectl-ai@latest
# 配置 LLM 后端
export OPENAI_API_KEY="your-api-key"
# 或使用 Gemini
export GOOGLE_API_KEY="your-api-key"使用示例
# 生成 Deployment
kubectl-ai "创建一个 nginx deployment,3 个副本,限制 CPU 200m 内存 256Mi"
# 生成带 PVC 的 StatefulSet
kubectl-ai "创建一个 PostgreSQL StatefulSet,使用 10Gi PVC,配置密码 secret"
# 生成 CronJob
kubectl-ai "创建一个每天凌晨 3 点运行的 CronJob,执行数据库备份脚本"
# 调试现有资源
kubectl-ai "为什么我的 pod myapp-xxx 一直 CrashLoopBackOff?"4.4 K8sGPT 集群诊断
K8sGPT 是一个开源的 AI 驱动 Kubernetes 诊断工具,可以用自然语言解释集群问题。
安装和使用
# 安装
brew install k8sgpt
# 配置 AI 后端
k8sgpt auth add --backend openai --model gpt-4o
# 分析集群问题
k8sgpt analyze
# 带 AI 解释的分析
k8sgpt analyze --explain
# 分析特定命名空间
k8sgpt analyze --namespace myapp --explain
# 过滤特定资源类型
k8sgpt filters list
k8sgpt analyze --filter Pod,Service --explain输出示例
0: Pod myapp/myapp-backend-7d8f9c6b4-x2k9m
- Error: Back-off restarting failed container
AI 解释:
该 Pod 的容器反复崩溃重启(CrashLoopBackOff)。
可能原因:
1. 应用启动失败(检查日志:kubectl logs myapp-backend-7d8f9c6b4-x2k9m)
2. 健康检查配置过于严格(startupProbe 超时太短)
3. 资源限制不足(OOMKilled)
4. 环境变量或配置缺失
建议操作:
- 查看 Pod 事件:kubectl describe pod myapp-backend-7d8f9c6b4-x2k9m -n myapp
- 查看容器日志:kubectl logs myapp-backend-7d8f9c6b4-x2k9m -n myapp --previous
- 检查资源使用:kubectl top pod -n myapp5. AI 辅助 Helm Chart 生成
5.1 Helm Chart 生成概述
Helm 是 Kubernetes 的包管理器,AI 可以大幅加速 Helm Chart 的创建和维护。据实践数据,AI 辅助可以将 Chart 创建时间从 4 小时缩短到 45 分钟,同时消除 YAML 语法错误。
5.2 Helm Chart 生成提示词模板
提示词模板:完整 Helm Chart
请为以下应用生成完整的 Helm Chart:
应用信息:
- 名称:[应用名]
- 类型:[Web 应用 / API 服务 / Worker / CronJob]
- 镜像:[镜像仓库地址]
- 端口:[应用端口]
- 依赖服务:[如 PostgreSQL、Redis]
Chart 要求:
1. 支持多环境部署(dev/staging/prod)
2. 可配置的副本数、资源限制、镜像标签
3. 可选的 Ingress 配置(含 TLS)
4. 可选的 HPA 配置
5. 可选的 PDB 配置
6. ConfigMap 和 Secret 管理
7. 健康检查探针配置
8. ServiceAccount 和 RBAC
9. 支持 Kustomize 覆盖
10. 包含 NOTES.txt 部署后提示
请生成完整的 Chart 目录结构和所有文件。示例:Helm Chart 目录结构
myapp-chart/
├── Chart.yaml # Chart 元数据
├── values.yaml # 默认配置值
├── values-dev.yaml # 开发环境覆盖
├── values-staging.yaml # 预发布环境覆盖
├── values-prod.yaml # 生产环境覆盖
├── templates/
│ ├── _helpers.tpl # 模板辅助函数
│ ├── namespace.yaml # 命名空间
│ ├── serviceaccount.yaml # 服务账户
│ ├── configmap.yaml # 配置映射
│ ├── secret.yaml # 密钥
│ ├── deployment.yaml # 部署
│ ├── service.yaml # 服务
│ ├── ingress.yaml # 入口(可选)
│ ├── hpa.yaml # 自动扩缩(可选)
│ ├── pdb.yaml # Pod 中断预算(可选)
│ ├── networkpolicy.yaml # 网络策略(可选)
│ └── NOTES.txt # 部署后提示
└── .helmignore # 忽略文件Chart.yaml
apiVersion: v2
name: myapp
description: A Helm chart for MyApp backend service
type: application
version: 0.1.0
appVersion: "1.0.0"
maintainers:
- name: DevOps Team
email: devops@example.com
keywords:
- backend
- api
- nodejsvalues.yaml(默认配置)
# 全局配置
global:
environment: production
# 镜像配置
image:
repository: registry.example.com/myapp-backend
tag: "1.0.0"
pullPolicy: IfNotPresent
# 副本数
replicaCount: 3
# 服务账户
serviceAccount:
create: true
name: ""
annotations: {}
# 容器端口
containerPort: 8080
# 服务配置
service:
type: ClusterIP
port: 80
# Ingress 配置
ingress:
enabled: true
className: nginx
annotations:
nginx.ingress.kubernetes.io/ssl-redirect: "true"
cert-manager.io/cluster-issuer: "letsencrypt-prod"
hosts:
- host: api.myapp.example.com
paths:
- path: /
pathType: Prefix
tls:
- secretName: myapp-tls
hosts:
- api.myapp.example.com
# 资源限制
resources:
requests:
cpu: 100m
memory: 128Mi
limits:
cpu: 500m
memory: 512Mi
# 自动扩缩
autoscaling:
enabled: true
minReplicas: 3
maxReplicas: 10
targetCPUUtilizationPercentage: 70
targetMemoryUtilizationPercentage: 80
# Pod 中断预算
podDisruptionBudget:
enabled: true
minAvailable: 2
# 探针配置
probes:
startup:
enabled: true
path: /health
initialDelaySeconds: 5
periodSeconds: 5
failureThreshold: 30
readiness:
enabled: true
path: /health/ready
periodSeconds: 10
timeoutSeconds: 3
liveness:
enabled: true
path: /health/live
periodSeconds: 15
timeoutSeconds: 3
# 环境变量(非敏感)
config:
APP_ENV: "production"
LOG_LEVEL: "info"
CORS_ORIGINS: "https://myapp.example.com"
# 敏感环境变量(引用 Secret)
secrets:
DATABASE_URL: ""
REDIS_URL: ""
JWT_SECRET: ""
# 安全上下文
securityContext:
runAsNonRoot: true
runAsUser: 1001
runAsGroup: 1001
fsGroup: 1001
containerSecurityContext:
allowPrivilegeEscalation: false
readOnlyRootFilesystem: true
capabilities:
drop: ["ALL"]
# 网络策略
networkPolicy:
enabled: true
# 节点选择和容忍
nodeSelector: {}
tolerations: []
affinity: {}核心模板:deployment.yaml
{{- /* templates/deployment.yaml */ -}}
apiVersion: apps/v1
kind: Deployment
metadata:
name: {{ include "myapp.fullname" . }}
namespace: {{ .Release.Namespace }}
labels:
{{- include "myapp.labels" . | nindent 4 }}
spec:
{{- if not .Values.autoscaling.enabled }}
replicas: {{ .Values.replicaCount }}
{{- end }}
revisionHistoryLimit: 5
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 1
maxUnavailable: 0
selector:
matchLabels:
{{- include "myapp.selectorLabels" . | nindent 6 }}
template:
metadata:
labels:
{{- include "myapp.selectorLabels" . | nindent 8 }}
annotations:
checksum/config: {{ include (print $.Template.BasePath "/configmap.yaml") . | sha256sum }}
checksum/secret: {{ include (print $.Template.BasePath "/secret.yaml") . | sha256sum }}
spec:
serviceAccountName: {{ include "myapp.serviceAccountName" . }}
automountServiceAccountToken: false
securityContext:
{{- toYaml .Values.securityContext | nindent 8 }}
terminationGracePeriodSeconds: 30
containers:
- name: {{ .Chart.Name }}
image: "{{ .Values.image.repository }}:{{ .Values.image.tag | default .Chart.AppVersion }}"
imagePullPolicy: {{ .Values.image.pullPolicy }}
ports:
- name: http
containerPort: {{ .Values.containerPort }}
protocol: TCP
envFrom:
- configMapRef:
name: {{ include "myapp.fullname" . }}-config
- secretRef:
name: {{ include "myapp.fullname" . }}-secrets
resources:
{{- toYaml .Values.resources | nindent 12 }}
securityContext:
{{- toYaml .Values.containerSecurityContext | nindent 12 }}
{{- if .Values.probes.startup.enabled }}
startupProbe:
httpGet:
path: {{ .Values.probes.startup.path }}
port: http
initialDelaySeconds: {{ .Values.probes.startup.initialDelaySeconds }}
periodSeconds: {{ .Values.probes.startup.periodSeconds }}
failureThreshold: {{ .Values.probes.startup.failureThreshold }}
{{- end }}
{{- if .Values.probes.readiness.enabled }}
readinessProbe:
httpGet:
path: {{ .Values.probes.readiness.path }}
port: http
periodSeconds: {{ .Values.probes.readiness.periodSeconds }}
timeoutSeconds: {{ .Values.probes.readiness.timeoutSeconds }}
{{- end }}
{{- if .Values.probes.liveness.enabled }}
livenessProbe:
httpGet:
path: {{ .Values.probes.liveness.path }}
port: http
periodSeconds: {{ .Values.probes.liveness.periodSeconds }}
timeoutSeconds: {{ .Values.probes.liveness.timeoutSeconds }}
{{- end }}
volumeMounts:
- name: tmp
mountPath: /tmp
volumes:
- name: tmp
emptyDir:
sizeLimit: 100Mi
{{- with .Values.nodeSelector }}
nodeSelector:
{{- toYaml . | nindent 8 }}
{{- end }}
{{- with .Values.affinity }}
affinity:
{{- toYaml . | nindent 8 }}
{{- end }}
{{- with .Values.tolerations }}
tolerations:
{{- toYaml . | nindent 8 }}
{{- end }}多环境部署
# values-dev.yaml
global:
environment: development
replicaCount: 1
image:
tag: "dev-latest"
resources:
requests:
cpu: 50m
memory: 64Mi
limits:
cpu: 200m
memory: 256Mi
autoscaling:
enabled: false
ingress:
hosts:
- host: api-dev.myapp.example.com
paths:
- path: /
pathType: Prefix
config:
APP_ENV: "development"
LOG_LEVEL: "debug"# values-prod.yaml
global:
environment: production
replicaCount: 5
image:
tag: "1.0.0"
resources:
requests:
cpu: 200m
memory: 256Mi
limits:
cpu: 1000m
memory: 1Gi
autoscaling:
enabled: true
minReplicas: 5
maxReplicas: 20
podDisruptionBudget:
enabled: true
minAvailable: 3# 部署到不同环境
helm upgrade --install myapp ./myapp-chart -f values-dev.yaml -n myapp-dev
helm upgrade --install myapp ./myapp-chart -f values-staging.yaml -n myapp-staging
helm upgrade --install myapp ./myapp-chart -f values-prod.yaml -n myapp-prod5.3 AI 辅助 Helm Chart 调试
提示词模板:Helm Chart 调试
我的 Helm Chart 部署后出现以下问题:
错误信息:
[粘贴 helm install/upgrade 的错误输出]
Chart 配置:
[粘贴相关的 values.yaml 和模板文件]
请帮我:
1. 分析错误原因
2. 提供修复方案
3. 建议如何预防类似问题
调试命令参考:
- helm template myapp ./myapp-chart -f values.yaml(渲染模板)
- helm lint ./myapp-chart(语法检查)
- helm install --dry-run --debug myapp ./myapp-chart(模拟安装)6. 容器安全扫描与最佳实践
6.1 容器安全工具对比
| 工具 | 类型 | 价格 | 特色 | 适用场景 |
|---|---|---|---|---|
| Docker Scout | 镜像漏洞扫描 + SBOM | Docker Pro $5/月起(含 Scout) | Docker 原生集成、持续 CVE 监控、修复建议 | Docker Desktop 用户、CI/CD 集成 |
| Snyk Container | 镜像 + K8s 配置扫描 | Free 有限扫描;Team $25/月起 | MCP Server 支持、Agentic 安全、基础镜像推荐 | AI 驱动安全工作流、企业级 |
| Trivy | 全面安全扫描 | 开源免费 | 镜像/IaC/SBOM/密钥扫描、CI/CD 友好 | 开源项目、CI/CD 管线 |
| Grype | 镜像漏洞扫描 | 开源免费 | 快速扫描、SBOM 集成(Syft) | 轻量级扫描需求 |
| Aikido Security | 全栈应用安全 | Free 版可用;Pro 定制 | 容器+依赖+IaC+SAST 统一平台 | 全面安全管理 |
| Aqua Security | 容器运行时安全 | 商业定制 | 运行时保护、合规审计、策略执行 | 企业级容器安全 |
| Falco | 运行时威胁检测 | 开源免费 | 内核级监控、异常行为检测 | K8s 运行时安全 |
6.2 Docker Scout 实战
Docker Scout 是 Docker 原生的安全扫描工具,内置于 Docker Desktop 和 CLI 中。
基本使用
# 扫描本地镜像
docker scout cves myapp:latest
# 快速概览
docker scout quickview myapp:latest
# 生成 SBOM
docker scout sbom myapp:latest
# 对比两个镜像的安全差异
docker scout compare myapp:1.0.0 myapp:1.1.0
# 查看修复建议
docker scout recommendations myapp:latest
# 策略评估
docker scout policy myapp:latestCI/CD 集成(GitHub Actions)
# .github/workflows/docker-security.yml
name: Docker Security Scan
on:
push:
branches: [main]
pull_request:
branches: [main]
jobs:
scan:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Build image
run: docker build -t myapp:${{ github.sha }} .
- name: Docker Scout scan
uses: docker/scout-action@v1
with:
command: cves,recommendations
image: myapp:${{ github.sha }}
sarif-file: scout-results.sarif
# 高危漏洞时失败
exit-code: true
only-severities: critical,high
- name: Upload SARIF
if: always()
uses: github/codeql-action/upload-sarif@v3
with:
sarif_file: scout-results.sarif6.3 Snyk Container + MCP Server
2025 年 Snyk 推出了 MCP Server,实现了 Agentic 容器安全扫描——AI 编码助手可以在生成容器配置的同时自动进行安全检查。
Snyk MCP Server 配置
// Claude Code .mcp.json
{
"mcpServers": {
"snyk": {
"command": "npx",
"args": ["-y", "@snyk/mcp-server"],
"env": {
"SNYK_TOKEN": "your-snyk-token"
}
}
}
}AI 辅助安全扫描工作流
@snyk 请扫描我刚生成的 Dockerfile 和镜像:
1. 检查基础镜像 node:20-alpine 是否有已知漏洞
2. 推荐更安全的替代基础镜像
3. 分析 Dockerfile 中的安全配置问题
4. 扫描应用依赖的漏洞Snyk CLI 使用
# 安装 Snyk CLI
npm install -g snyk
# 认证
snyk auth
# 扫描容器镜像
snyk container test myapp:latest
# 扫描并获取修复建议
snyk container test myapp:latest --severity-threshold=high
# 监控镜像(持续监控新漏洞)
snyk container monitor myapp:latest
# 扫描 Dockerfile
snyk container test --file=Dockerfile myapp:latest
# 扫描 K8s 配置
snyk iac test k8s/6.4 Trivy 全面扫描
# 安装 Trivy
brew install trivy
# 扫描容器镜像
trivy image myapp:latest
# 仅显示高危和严重漏洞
trivy image --severity HIGH,CRITICAL myapp:latest
# 扫描 Dockerfile
trivy config Dockerfile
# 扫描 K8s manifests
trivy config k8s/
# 扫描 Helm Chart
trivy config myapp-chart/
# 生成 SBOM
trivy image --format spdx-json -o sbom.json myapp:latest
# CI/CD 集成:发现高危漏洞时退出码非零
trivy image --exit-code 1 --severity HIGH,CRITICAL myapp:latestTrivy CI/CD 集成(GitHub Actions)
- name: Trivy vulnerability scan
uses: aquasecurity/trivy-action@master
with:
image-ref: myapp:${{ github.sha }}
format: sarif
output: trivy-results.sarif
severity: CRITICAL,HIGH
exit-code: "1"6.5 AI 辅助安全修复工作流
提示词模板:容器安全修复
以下是我的容器镜像安全扫描结果:
[粘贴 Docker Scout / Snyk / Trivy 的扫描输出]
请帮我:
1. 按严重程度分类所有漏洞
2. 识别哪些漏洞可以通过升级基础镜像修复
3. 识别哪些漏洞需要升级应用依赖
4. 识别哪些漏洞是误报或不影响我的应用
5. 提供修复后的 Dockerfile
6. 建议长期的安全维护策略
当前 Dockerfile:
[粘贴 Dockerfile]
当前基础镜像:[如 node:20-alpine]安全扫描自动化管线
# .github/workflows/container-security-pipeline.yml
name: Container Security Pipeline
on:
push:
branches: [main]
schedule:
# 每天扫描一次(检测新发现的漏洞)
- cron: "0 6 * * *"
jobs:
build-and-scan:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Build image
run: docker build -t myapp:${{ github.sha }} .
# 第一层:Dockerfile 静态分析
- name: Hadolint Dockerfile lint
uses: hadolint/hadolint-action@v3
with:
dockerfile: Dockerfile
# 第二层:镜像漏洞扫描
- name: Trivy image scan
uses: aquasecurity/trivy-action@master
with:
image-ref: myapp:${{ github.sha }}
format: table
severity: CRITICAL,HIGH
exit-code: "1"
# 第三层:K8s 配置扫描
- name: Trivy config scan
uses: aquasecurity/trivy-action@master
with:
scan-type: config
scan-ref: k8s/
severity: CRITICAL,HIGH
# 第四层:密钥泄露检测
- name: Trivy secret scan
uses: aquasecurity/trivy-action@master
with:
scan-type: fs
scan-ref: .
scanners: secret
severity: CRITICAL,HIGH
# 通知
- name: Notify on failure
if: failure()
uses: slackapi/slack-github-action@v1
with:
payload: |
{
"text": "⚠️ 容器安全扫描发现问题!\n仓库: ${{ github.repository }}\n分支: ${{ github.ref_name }}\n详情: ${{ github.server_url }}/${{ github.repository }}/actions/runs/${{ github.run_id }}"
}
env:
SLACK_WEBHOOK_URL: ${{ secrets.SLACK_WEBHOOK }}7. AI 辅助容器化 Steering 规则
7.1 Dockerfile Steering 规则模板
在项目的 Steering 规则文件(如 CLAUDE.md、.cursorrules、.kiro/steering/)中添加以下容器化规则,可以让 AI 编码助手在生成容器配置时自动遵循最佳实践:
# 容器化规则
## Dockerfile 规则
- 所有 Dockerfile 必须使用多阶段构建
- 最终阶段必须使用 alpine 或 slim 基础镜像
- 必须以非 root 用户运行(USER 指令)
- 必须包含 HEALTHCHECK 指令
- 必须固定基础镜像版本(禁止使用 latest 标签)
- 使用 COPY 而非 ADD(除非需要解压)
- 先复制依赖文件再复制源码(优化层缓存)
- 合并 RUN 指令并清理包管理器缓存
- 使用 .dockerignore 排除不必要的文件
- 添加 OCI 标签(LABEL 指令)
## Docker Compose 规则
- 所有服务必须配置 healthcheck
- 使用 depends_on + condition: service_healthy
- 配置资源限制(deploy.resources.limits)
- 使用命名卷持久化数据
- 敏感信息使用 .env 文件,不硬编码
- 配置日志驱动和大小限制
- 使用自定义网络隔离服务
- 后端网络设置 internal: true
## Kubernetes 规则
- 所有 Deployment 必须配置 readinessProbe 和 livenessProbe
- 必须设置资源 requests 和 limits
- 使用 SecurityContext(runAsNonRoot、readOnlyRootFilesystem)
- 配置 PodDisruptionBudget
- 使用标准标签(app.kubernetes.io/*)
- Secret 不硬编码在 manifests 中
- 配置 NetworkPolicy 限制网络访问
- 使用 RollingUpdate 策略,maxUnavailable: 07.2 Claude Code Skills:Docker 容器化
# Docker Containerization Skill
## 触发条件
当用户请求生成 Dockerfile、docker-compose.yml 或 K8s manifests 时激活。
## 行为规则
1. 分析项目结构,识别语言/框架/依赖
2. 生成多阶段 Dockerfile,遵循安全最佳实践
3. 生成 .dockerignore 文件
4. 如果是多服务项目,生成 docker-compose.yml
5. 提供构建和运行命令
6. 建议安全扫描命令
## 检查清单
- [ ] 多阶段构建
- [ ] 非 root 用户
- [ ] HEALTHCHECK
- [ ] 固定版本
- [ ] .dockerignore
- [ ] 层缓存优化实战案例:从零到生产的全栈应用容器化
案例背景
一个全栈 SaaS 应用需要容器化部署到 Kubernetes 集群:
- 前端:Next.js 14(TypeScript)
- 后端:FastAPI(Python 3.12)
- 数据库:PostgreSQL 16
- 缓存:Redis 7
- 对象存储:MinIO
- 反向代理:Nginx
步骤 1:使用 AI 分析项目结构
请分析以下项目结构,为每个服务推荐最优的容器化方案:
项目结构:
├── frontend/ # Next.js 14, pnpm
│ ├── package.json
│ ├── pnpm-lock.yaml
│ ├── next.config.js
│ └── src/
├── backend/ # FastAPI, Python 3.12, poetry
│ ├── pyproject.toml
│ ├── poetry.lock
│ └── app/
├── nginx/ # Nginx 配置
│ └── nginx.conf
└── docker-compose.yml
请为每个服务推荐:
1. 基础镜像选择
2. 多阶段构建策略
3. 预估最终镜像大小
4. 安全加固要点步骤 2:AI 生成前端 Dockerfile
# frontend/Dockerfile
# ============================================
# 阶段 1:依赖安装
# ============================================
FROM node:20-alpine AS deps
RUN corepack enable && corepack prepare pnpm@9 --activate
WORKDIR /app
COPY package.json pnpm-lock.yaml ./
RUN pnpm install --frozen-lockfile
# ============================================
# 阶段 2:构建
# ============================================
FROM node:20-alpine AS builder
RUN corepack enable && corepack prepare pnpm@9 --activate
WORKDIR /app
COPY --from=deps /app/node_modules ./node_modules
COPY . .
# Next.js 构建时环境变量
ARG NEXT_PUBLIC_API_URL
ENV NEXT_PUBLIC_API_URL=$NEXT_PUBLIC_API_URL
RUN pnpm build
# ============================================
# 阶段 3:运行(standalone 模式)
# ============================================
FROM node:20-alpine AS runner
RUN addgroup -g 1001 -S appgroup && \
adduser -S appuser -u 1001 -G appgroup
WORKDIR /app
ENV NODE_ENV=production
ENV NEXT_TELEMETRY_DISABLED=1
# Next.js standalone 输出只需要这些文件
COPY --from=builder --chown=appuser:appgroup /app/.next/standalone ./
COPY --from=builder --chown=appuser:appgroup /app/.next/static ./.next/static
COPY --from=builder --chown=appuser:appgroup /app/public ./public
USER appuser
EXPOSE 3000
HEALTHCHECK --interval=30s --timeout=3s --start-period=20s \
CMD wget --no-verbose --tries=1 --spider http://localhost:3000/api/health || exit 1
CMD ["node", "server.js"]
# 预估镜像大小:~120MB步骤 3:AI 生成后端 Dockerfile
# backend/Dockerfile
# ============================================
# 阶段 1:依赖安装
# ============================================
FROM python:3.12-slim AS builder
RUN pip install poetry==1.8.3 && \
poetry config virtualenvs.create false
WORKDIR /app
COPY pyproject.toml poetry.lock ./
RUN --mount=type=cache,target=/root/.cache/pip \
poetry install --no-dev --no-interaction --no-ansi
# ============================================
# 阶段 2:运行
# ============================================
FROM python:3.12-slim AS runner
RUN apt-get update && \
apt-get install -y --no-install-recommends curl libpq5 && \
rm -rf /var/lib/apt/lists/* && \
groupadd -r appgroup && \
useradd -r -g appgroup -d /app appuser
WORKDIR /app
# 从构建阶段复制已安装的包
COPY --from=builder /usr/local/lib/python3.12/site-packages /usr/local/lib/python3.12/site-packages
COPY --from=builder /usr/local/bin /usr/local/bin
COPY --chown=appuser:appgroup . .
ENV PYTHONUNBUFFERED=1
ENV PYTHONDONTWRITEBYTECODE=1
USER appuser
EXPOSE 8000
HEALTHCHECK --interval=30s --timeout=3s --start-period=15s \
CMD curl -f http://localhost:8000/health || exit 1
CMD ["uvicorn", "app.main:app", "--host", "0.0.0.0", "--port", "8000", "--workers", "4"]
# 预估镜像大小:~180MB步骤 4:AI 生成 K8s 部署配置
使用 AI 生成完整的 Kustomize 结构:
myapp-k8s/
├── base/
│ ├── kustomization.yaml
│ ├── namespace.yaml
│ ├── frontend/
│ │ ├── deployment.yaml
│ │ ├── service.yaml
│ │ └── hpa.yaml
│ ├── backend/
│ │ ├── deployment.yaml
│ │ ├── service.yaml
│ │ ├── hpa.yaml
│ │ └── configmap.yaml
│ ├── postgres/
│ │ ├── statefulset.yaml
│ │ ├── service.yaml
│ │ ├── pvc.yaml
│ │ └── secret.yaml
│ ├── redis/
│ │ ├── deployment.yaml
│ │ └── service.yaml
│ ├── ingress.yaml
│ └── networkpolicy.yaml
├── overlays/
│ ├── dev/
│ │ ├── kustomization.yaml
│ │ └── patches/
│ ├── staging/
│ │ ├── kustomization.yaml
│ │ └── patches/
│ └── prod/
│ ├── kustomization.yaml
│ └── patches/base/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
namespace: myapp
resources:
- namespace.yaml
- frontend/deployment.yaml
- frontend/service.yaml
- frontend/hpa.yaml
- backend/deployment.yaml
- backend/service.yaml
- backend/hpa.yaml
- backend/configmap.yaml
- postgres/statefulset.yaml
- postgres/service.yaml
- postgres/pvc.yaml
- postgres/secret.yaml
- redis/deployment.yaml
- redis/service.yaml
- ingress.yaml
- networkpolicy.yaml
commonLabels:
app.kubernetes.io/part-of: myapp-platform
app.kubernetes.io/managed-by: kustomizeoverlays/prod/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- ../../base
namespace: myapp-prod
patches:
# 生产环境:增加副本数
- target:
kind: Deployment
name: myapp-frontend
patch: |
- op: replace
path: /spec/replicas
value: 5
- target:
kind: Deployment
name: myapp-backend
patch: |
- op: replace
path: /spec/replicas
value: 5
# 生产环境:增加资源限制
- target:
kind: Deployment
name: myapp-backend
patch: |
- op: replace
path: /spec/template/spec/containers/0/resources/limits/memory
value: 1Gi
- op: replace
path: /spec/template/spec/containers/0/resources/limits/cpu
value: "1"步骤 5:安全扫描与修复
# 构建镜像
docker build -t myapp-frontend:1.0.0 ./frontend
docker build -t myapp-backend:1.0.0 ./backend
# Docker Scout 扫描
docker scout cves myapp-frontend:1.0.0
docker scout cves myapp-backend:1.0.0
# Trivy 扫描
trivy image --severity HIGH,CRITICAL myapp-frontend:1.0.0
trivy image --severity HIGH,CRITICAL myapp-backend:1.0.0
# K8s 配置扫描
trivy config myapp-k8s/
# 将扫描结果交给 AI 分析和修复步骤 6:部署验证
# 渲染 Kustomize 配置(检查生成的 YAML)
kubectl kustomize myapp-k8s/overlays/prod
# 部署到生产环境
kubectl apply -k myapp-k8s/overlays/prod
# 验证部署状态
kubectl get all -n myapp-prod
kubectl get ingress -n myapp-prod
# 使用 K8sGPT 检查潜在问题
k8sgpt analyze --namespace myapp-prod --explain案例分析
| 维度 | AI 辅助前 | AI 辅助后 |
|---|---|---|
| Dockerfile 编写时间 | 2-3 小时/服务 | 15-30 分钟/服务 |
| K8s Manifests 编写时间 | 4-6 小时 | 45-60 分钟 |
| Helm Chart 创建时间 | 4-8 小时 | 45-90 分钟 |
| 安全问题发现 | 部署后被动发现 | 构建时主动扫描 |
| 镜像大小 | 500MB-1GB(未优化) | 100-200MB(多阶段+alpine) |
| 配置错误率 | 频繁的 YAML 语法错误 | 接近零语法错误 |
| 最佳实践覆盖 | 依赖个人经验 | 系统化检查清单 |
避坑指南
❌ 常见错误
-
使用
latest标签作为基础镜像- 问题:
FROM node:latest会导致构建不可重复,不同时间构建可能得到不同版本的 Node.js,引发难以排查的兼容性问题。安全扫描也无法准确追踪基础镜像版本。 - 正确做法:固定完整版本号
FROM node:20.11.1-alpine3.19,在 CI/CD 中定期更新并测试新版本。
- 问题:
-
以 root 用户运行容器
- 问题:默认情况下容器以 root 运行,如果容器被攻破,攻击者将获得 root 权限,可能逃逸到宿主机。这是容器安全的头号风险。
- 正确做法:创建专用用户
RUN adduser -S appuser,使用USER appuser切换,运行时加--cap-drop ALL。
-
单阶段构建导致镜像臃肿
- 问题:将构建工具(gcc、make、npm devDependencies)留在最终镜像中,导致镜像体积膨胀到 1GB+,增加攻击面和拉取时间。
- 正确做法:使用多阶段构建,构建阶段安装所有工具,运行阶段只复制必要的产物和运行时依赖。
-
在 Dockerfile 中硬编码密钥
- 问题:
ENV API_KEY=sk-xxx会将密钥写入镜像层,即使后续删除也可以从历史层中恢复。推送到镜像仓库后密钥永久泄露。 - 正确做法:使用
--mount=type=secret传递构建时密钥,运行时通过环境变量或 K8s Secret 注入。
- 问题:
-
忽略 .dockerignore 文件
- 问题:不配置 .dockerignore 会将
.git(可能几百 MB)、node_modules、.env文件等全部复制到构建上下文,导致构建缓慢且可能泄露敏感信息。 - 正确做法:创建 .dockerignore 排除
.git、node_modules、.env、*.log、测试文件等。
- 问题:不配置 .dockerignore 会将
-
Docker Compose 中不配置健康检查
- 问题:没有 healthcheck 时,
depends_on只等待容器启动而非服务就绪,导致依赖服务(如数据库)还未准备好时应用就开始连接,引发启动失败。 - 正确做法:为每个服务配置 healthcheck,使用
depends_on: condition: service_healthy确保依赖服务真正就绪。
- 问题:没有 healthcheck 时,
-
K8s Deployment 不配置资源限制
- 问题:不设置
resources.limits时,单个 Pod 可能消耗整个节点的资源,导致其他 Pod 被驱逐。不设置resources.requests时,调度器无法合理分配 Pod。 - 正确做法:始终设置 requests 和 limits,requests 基于实际使用量,limits 设置合理上限。使用 VPA 或监控数据调优。
- 问题:不设置
-
K8s 中不配置探针或探针配置不当
- 问题:不配置 readinessProbe 会导致未就绪的 Pod 接收流量;livenessProbe 配置过于激进会导致健康的 Pod 被频繁重启(“探针风暴”)。
- 正确做法:分别配置 startupProbe(慢启动)、readinessProbe(流量控制)、livenessProbe(故障恢复),设置合理的超时和重试次数。
-
Helm Chart 中硬编码环境特定值
- 问题:在 templates 中直接写入生产环境的域名、IP、密钥等,导致 Chart 无法在不同环境复用。
- 正确做法:所有环境特定值放入 values.yaml,使用
values-dev.yaml、values-prod.yaml覆盖,敏感值使用 External Secrets Operator。
-
忽略容器安全扫描
- 问题:不扫描镜像就部署到生产环境,可能包含已知的高危漏洞(如 Log4Shell、OpenSSL 漏洞),成为攻击入口。
- 正确做法:在 CI/CD 管线中集成 Docker Scout/Trivy/Snyk 扫描,设置高危漏洞阻断策略,定期扫描已部署的镜像。
✅ 最佳实践
- 镜像构建:始终使用多阶段构建 + 最小基础镜像(alpine/slim/distroless/scratch),目标是最终镜像只包含运行时必需的文件
- 安全第一:非 root 用户、只读文件系统、最小权限、固定版本、定期扫描,将安全检查集成到 CI/CD 管线
- 缓存优化:利用 Docker 层缓存和 BuildKit 缓存挂载加速构建,依赖文件变化频率低于源码,应先复制
- 配置管理:使用 Kustomize 或 Helm 管理多环境配置,敏感信息通过 Secret 管理,不硬编码
- 可观测性:所有容器配置 HEALTHCHECK/探针,集成日志收集和监控,使用 K8sGPT 辅助诊断
- AI 辅助审查:生成容器配置后,使用 AI 进行安全审查和优化建议,将 Steering 规则集成到开发工作流
相关资源与延伸阅读
- Docker MCP Toolkit + Claude Code 指南 — Docker 官方指南,展示如何用 Claude Code 通过 MCP Toolkit 生成 Docker Compose 栈
- K8sGPT 项目 — 开源 AI 驱动的 Kubernetes 诊断工具,用自然语言解释集群问题(GitHub 7k+ Stars)
- kubectl-ai 项目 — kubectl 插件,用自然语言生成 K8s manifests,支持 OpenAI 和 Gemini
- Snyk MCP Server 容器安全 — Snyk 官方博客,介绍 Agentic 容器安全扫描工作流
- DeveloperToolkit.ai Docker 模式 — AI 辅助容器化最佳实践模式库,覆盖多阶段构建、安全加固、Compose 编排
- DeveloperToolkit.ai K8s 模式 — AI 辅助 K8s manifest 生成、Helm Chart、GitOps 工作流模式
- Docker Scout 文档 — Docker 原生安全扫描工具完整文档,包含 CLI 使用、CI/CD 集成、策略配置
- Trivy 项目 — Aqua Security 开源的全面安全扫描工具,支持镜像、IaC、SBOM 扫描(GitHub 25k+ Stars)
- Workik Docker 代码生成器 — 免费在线 AI Docker 配置生成工具
- Workik Kubernetes 代码生成器 — 免费在线 AI K8s YAML 和 Helm Chart 生成工具
参考来源
- Generate Docker Compose Files with Claude Code and Docker MCP Toolkit (2025-06)
- Agentic Container Security with Snyk MCP Server (2025-08)
- Beyond the Scan: The Future of Snyk Container (2025-11)
- How Docker Hardened Images Patch CVEs in 24 Hours (2025-11)
- Docker Scout: Scan Container Images for Vulnerabilities (2026-02)
- Docker Scout vs Trivy for Vulnerability Scanning (2026-02)
- Container Security for AI Applications 2026 (2026-02)
- Top 13 Container Scanning Tools in 2026 (2025-12)
- Automatic Dockerfile Generation with Large Language Models (ICSE 2026) (2026)
- AI Docker v25 Build Optimization (2026-02)
- AI Helm Chart Generation: 80% Time Savings (2026-02)
- Docker and Kubernetes Setup via CLI with AI (2026-02)
- Kubernetes Orchestration Patterns with AI (2026-02)
- Secure AI Agents at Runtime with Docker (2025-09)
- Docker at Black Hat 2025: Secure Software Supply Chains (2025-08)
- Dockerfile Best Practices — fast builds, small images, safer containers (2025-09)
📖 返回 总览与导航 | 上一节:32c-AI辅助CI-CD配置 | 下一节:32e-AI辅助监控与事件响应