DevOps 与自动化

DevOps 的日常一半是写 YAML。Claude Code 恰好是 YAML 的敌人。

Docker 配置、Kubernetes manifest、GitHub Actions workflow、Terraform 模块、Ansible playbook，这些东西本质上都是把领域知识翻译成 YAML 或 HCL 结构。翻译工作是大模型的强项。你只要把意图说清楚，Claude Code 就能把结构写对，还会顺手把最佳实践塞进去。

这一节走四个场景，覆盖容器化、编排、CI 自动化、基础设施代码。

场景一：给 Node.js 项目生成多阶段 Dockerfile 和 compose

假设你手上有一个 Node.js 20 + pnpm + TypeScript 的项目，还没有容器化。目标是一个生产级的 Dockerfile，用多阶段构建，跑非 root 用户，配上一份本地开发用的 docker-compose。

> 帮我给这个项目生成生产级容器化方案：
> 1. Dockerfile 用多阶段构建，builder 阶段编译 TS，runner 阶段只留必要产物
> 2. 用 node:20-alpine 作为 base，跑 non-root 用户
> 3. 使用 pnpm，善用 pnpm fetch 做 layer 缓存
> 4. 加健康检查 HEALTHCHECK
> 5. 生成 docker-compose.yml，包含 app 服务、postgres 服务、redis 服务
> 6. 敏感变量走 .env，同时给一份 .env.example
> 7. 生成 .dockerignore

Claude Code 会先扫 package.json 里的 scripts、tsconfig.json 的 outDir 配置，然后一次性把 Dockerfile、compose、.dockerignore、.env.example 全部生成好。多阶段构建的关键点它会自动照顾到，比如把 node_modules 拆成 deps 阶段单独缓存，最终镜像里只留 dist/ 和运行时依赖。

一个典型的输出片段会长这样。

dockerfile

FROM node:20-alpine AS deps
WORKDIR /app
RUN corepack enable
COPY package.json pnpm-lock.yaml ./
RUN --mount=type=cache,id=pnpm,target=/root/.pnpm-store \
    pnpm fetch --frozen-lockfile

FROM node:20-alpine AS builder
WORKDIR /app
RUN corepack enable
COPY --from=deps /app/node_modules ./node_modules
COPY . .
RUN pnpm install --frozen-lockfile --offline
RUN pnpm run build

FROM node:20-alpine AS runner
WORKDIR /app
RUN addgroup -g 1001 -S nodejs && adduser -S nodejs -u 1001
COPY --from=builder --chown=nodejs:nodejs /app/dist ./dist
COPY --from=builder --chown=nodejs:nodejs /app/node_modules ./node_modules
COPY --from=builder --chown=nodejs:nodejs /app/package.json ./
USER nodejs
EXPOSE 3000
HEALTHCHECK --interval=30s --timeout=3s CMD wget -qO- http://localhost:3000/health || exit 1
CMD ["node", "dist/main.js"]

生成完 Claude Code 会主动跑一次 docker build 和 docker compose config 验证语法，遇到构建失败会自己回去改。审 diff 时你只要注意几件事：健康检查路径是不是真存在、.env.example 里有没有把 secret 值写进去、镜像最终大小是不是合理。

让它帮你算镜像瘦身

构建完让它跑 docker images 看大小，如果超过 200 MB 让它分析哪里可以再瘦。它通常会建议换成 distroless 或者干脆用 node:20-slim 加手动装 tini。

场景二：Kubernetes YAML 和 Helm chart

有了镜像下一步是部署。假设目标是 Kubernetes 集群，你想要一份最小可用的 deployment、service、ingress，再包成一个 Helm chart 便于多环境部署。

> 帮我生成 k8s manifest：
> 1. Deployment，3 副本，滚动更新，配好 resources.limits 和 requests
> 2. 加 readinessProbe 和 livenessProbe，路径 /health
> 3. Service 是 ClusterIP，端口 3000
> 4. Ingress 用 nginx-ingress，域名 app.example.com，加 cert-manager annotation
> 5. 敏感配置走 Secret，非敏感配置走 ConfigMap
> 6. 然后把这些改造成 Helm chart，放在 deploy/helm/myapp 下，values.yaml 暴露 image tag、副本数、域名三个字段

Claude Code 通常会分两步走。先写裸 YAML 让你看结构，跑 kubectl apply --dry-run=client -f 验证，通过后再改造成 Helm chart。改造过程会自动把硬编码的 image、replicas、host 拆到 values.yaml，模板里用 {{ .Values.image.tag }} 引用。

最后它会生成一份 helm template 的验证命令让你确认渲染出来的 YAML 和裸版本等价。

生产 manifest 别偷懒

resources、probes、securityContext 三样是生产 K8s 的最低门槛。Claude Code 有时会为了简化省掉某项，审 diff 时要主动补齐。可以在 CLAUDE.md 里写死一条规则，任何新的 Deployment 必须带这三样。

场景三：CI 里跑 headless Claude Code 做批量迁移

Claude Code 的 -p 模式加 --dangerously-skip-permissions 可以在 CI 里跑 headless，这打开了一片全新的自动化场景。最典型的例子是大规模 codemod。

比如你想把仓库里所有 console.log 换成 logger.info，同时补上正确的 logger 引入。传统做法是写 codemod 脚本，覆盖 AST 情况繁琐。让 Claude Code 直接跑。

yaml

# .github/workflows/codemod.yml
name: Codemod console to logger

on:
  workflow_dispatch:

jobs:
  codemod:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
      - run: npm install -g @anthropic-ai/claude-code
      - name: Run codemod
        env:
          ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
        run: |
          claude -p --dangerously-skip-permissions \
            "扫描 src 目录，把所有 console.log 换成 logger.info，
             如果文件里没有引入 logger 就从 @/lib/logger 引入。
             改完跑 npm test 和 npm run lint，全部通过前不算完成。"
      - name: Create PR
        uses: peter-evans/create-pull-request@v6
        with:
          title: 'chore: replace console.log with logger.info'
          branch: automation/codemod-logger

跑一次这个 workflow，就能收到一份完整的迁移 PR。类似的模式可以用在依赖升级、路径重构、批量翻译文案、批量补类型注解等一堆场景。

headless 模式的边界

--dangerously-skip-permissions 会跳过所有权限确认，等于让 Claude Code 在 CI 环境里全权动手。务必只在受控的 CI runner 里用，别在生产服务器或你的本机开这个开关。API key 通过 secrets 注入，不要落到日志里。

场景四：Terraform 和 Ansible 的辅助

基础设施代码写起来最累的是记 provider 的字段名。Claude Code 对 AWS、GCP、Aliyun 主要 provider 的 schema 都熟。

> 帮我写 Terraform 模块 modules/rds，参数暴露 identifier、instance_class、
> allocated_storage、engine、engine_version。
> 默认启用 storage_encrypted、backup_retention_period 7 天、
> multi_az、performance_insights_enabled。
> 输出 outputs 包含 endpoint、port、arn。
> 同时写一份 examples/complete/main.tf 展示用法。

它会连 provider 版本一起给你写好 versions.tf，variables.tf 里每个变量都带 description 和 type，main.tf 引用变量而不是硬编码。生成后跑 terraform init 和 terraform validate 会自动验证语法。

Ansible playbook 也是类似的思路。让 Claude Code 生成一份部署 Node.js app 的 playbook，它会自动拆成 tasks、handlers、templates 三个目录，符合官方 role 布局。

一些跨场景的经验

凡是 YAML 都让它跑一次 lint。yamllint、kubeval、hadolint、tflint、ansible-lint 这些工具在会话里都能跑起来。把 lint 作为验证环节写进 prompt，出问题它会自己回去改。你甚至可以在 CLAUDE.md 里写死一条硬规则，任何 Dockerfile 提交前必须过 hadolint，任何 K8s manifest 提交前必须过 kubeval，它会自觉执行。
多环境用 Helm 或 Kustomize，别搞多份 YAML。Claude Code 生成 Kustomize overlay 也很顺手，你说生成 base 和 dev、staging、prod 三个 overlay 就行。它会正确地把 namespace、replicas、image tag 这些差异化字段拆到 patches 里，base 保持干净。
写 CI workflow 时贴一份现有的做参考。Claude Code 会自动对齐你团队里已有的 workflow 风格，包括 caching 策略、matrix build 布局、secrets 命名约定。让它读 .github/workflows/ci.yml 再写新的 workflow，一致性会比从零生成好很多。
别让它写 Chart 的 helpers.tpl 无脑复制官方模板。helpers 里的 fullname、labels 这些函数是有约定俗成写法的，可以在 CLAUDE.md 里贴一份团队标准模板作为样板，它会照抄。
Terraform 生成完记得让它跑一次 terraform fmt 和 terraform validate，这两个命令基本零风险，可以在会话开头直接给权限。生产环境的 apply 别放心给它做，一律你自己动手。

场景五：日常运维查询

除了写基础设施代码，Claude Code 也可以做临时的运维查询。假设你要从 CloudWatch 或 Aliyun SLS 里捞过去一小时的错误日志，做一次分类。

> 用 aws cli 拉 /aws/lambda/api-prod 过去 60 分钟的日志，
> 过滤 level=ERROR 的行，按 error message 聚合，输出 top 10 类型和次数

它会写好 aws logs filter-log-events 命令，把返回的 JSON 用 jq 处理成表格。这类临时任务不值得写成正式脚本，用完就丢，非常适合 Claude Code。

Kubernetes 集群里的即席查询也类似。你可以让它跑 kubectl get pods -A 然后按重启次数排序，或者让它写一段 shell 循环，检查所有 namespace 里 pod 的 request/limit 是否合理。这种类型的活如果你自己每次都要现查 kubectl 用法，会比让 Claude Code 直接给出来慢很多。

DevOps 场景的核心心法是：把重复但高度结构化的活让给 Claude Code。你的注意力应该放在架构决策、容量规划、成本优化这些真正需要你判断的地方。YAML 的字段名和 provider 的 argument 名，实在没必要背在脑子里。

DevOps 与自动化 ​

场景一：给 Node.js 项目生成多阶段 Dockerfile 和 compose ​

场景二：Kubernetes YAML 和 Helm chart ​

场景三：CI 里跑 headless Claude Code 做批量迁移 ​

场景四：Terraform 和 Ansible 的辅助 ​

一些跨场景的经验 ​