第6节 部署：容器化与CI/CD集成一句话总结：Dockerfile与compose部署、密钥注入方案对比、定时任务（cron/systemd/Actions三选一）、版本升级与状态迁移；外加一份我每次上线前逐项打勾的检查清单。本文导航一、部署目标：换台机器十分钟跑起来二、容器化：Dockerfile与Compose三、密钥注入：三种方案对比四、定时任务：cron/systemd/Actions三选一五、版本升级与SQLite状态迁移六、部署脚本、备份与恢复演练七、上线检查、踩坑与监控值守小结一、部署目标：换台机器十分钟跑起来第5节结束时，流水线在我的开发机上已经跑得很漂亮了。但"在我机器上能跑"不是部署，部署的定义我给自己定得很硬：任何一台干净的Linux机器，装好Docker后十分钟内让流水线跑起来，且我的密钥从头到尾不落进任何Git仓库。这个目标拆开是四件事：容器化（环境标准化）、密钥注入（安全）、定时触发（无人值守）、状态迁移（升级不丢票）。整个交付链路：git push mainGitHub Actionslint+test+build镜像镜像仓库tag=git shaSSH到构建机docker compose pullcompose up -d滚动重启流水线数据卷不动tickets.db+logs保留健康检查失败自动回滚tag注意V那个节点：升级只换代码镜像，data/（SQLite票据库）和logs/（按月日志+原始提示词）挂在宿主机卷上，容器怎么重启都不丢。这个设计在第1节架构定稿时就埋下了——有状态的只有票据库，其他组件全部可抛弃，部署时这句架构原则直接兑现成docker volume。二、容器化：Dockerfile与Compose2.1 Dockerfile：分层缓存与非root直接上完整Dockerfile，每一层都有讲究：# Dockerfile FROM python:3.12-slim # 系统依赖：git是worktree必需，ca-certificates是HTTPS调用GitHub/LLM API必需 RUN apt-get update && apt-get install -y --no-install-recommends \ git ca-certificates \ && rm -rf /var/lib/apt/lists/* # 安装uv：从官方镜像拷贝二进制，不走pip COPY --from=ghcr.io/astral-sh/uv:latest /uv /usr/local/bin/uv WORKDIR /app # 第一层：只拷依赖清单，代码改动不触发依赖重装（缓存命中的关键） COPY pyproject.toml uv.lock ./ RUN uv sync --frozen --no-dev # --frozen：严格按lockfile，可复现 # 第二层：业务代码 COPY src/ src/ COPY pareto_config.yaml ./ # 非root运行：容器被攻破时少一层杀伤面 RUN useradd -m runner && chown -R runner:runner /app USER runner # 数据与日志目录：由compose挂载卷覆盖，这里只保证存在 VOLUME ["/app/data", "/app/logs"] # 健康检查：票据库可查=服务活着 HEALTHCHECK --interval=60s --timeout=10s --retries=3 \ CMD uv run python -c "import sqlite3; sqlite3.connect('/app/data/tickets.db').execute('SELECT 1 FROM tickets LIMIT 1')" || exit 1 CMD ["uv", "run", "python", "-m", "ai_loop_course.night_pipeline"]三个容易被忽略的点。分层顺序：依赖清单（pyproject.toml/uv.lock）单独一层放在代码前面，我改一行业务代码重新build时，依赖层直接命中缓存，构建从4分钟掉到25秒。非root：这条流水线会执行git操作和shell命令，容器逃逸的杀伤面必须收窄，加USER runner只要两行。HEALTHCHECK用业务语义：不是ping端口而是查票据库，"进程活着"和"系统可用"是两回事。构建与本地验证：# 构建镜像（tag用git短sha，部署和回滚都靠它）dockerbuild-tai-pipeline:$(gitrev-parse--shortHEAD).# 本地冒烟：跑一次分诊模块确认依赖齐、密钥能读到dockerrun--rm--env-file .env ai-pipeline:$(gitrev-parse--shortHEAD)\uv run python-mai_loop_course.triage_module--smoke[+] Building 24.7s (14/14) FINISHED => [internal] load build definition from Dockerfile => CACHED [deps 1/2] COPY pyproject.toml uv.lock ./ => CACHED [deps 2/2] RUN uv sync --frozen --no-dev ← 依赖层缓存命中 => [2/2] COPY src/ src/ => exporting to image ai-pipeline:9c41f2b Smoke test: triage_module 导入成功，pydantic模型校验通过，密钥已从环境变量读取（key=…f3a9c2）2.2 Compose：挂载、限流、健康检查单机部署用Compose足够（第1节选型表说过，K8s在这个规模是自虐）。完整配置：# docker-compose.ymlservices:pipeline:image:ai-pipeline:${TAG:-latest}# TAG由部署脚本注入git shaenv_file:.env# 密钥注入（见下一节）volumes:-./data:/app/data# SQLite票据库持久化-./logs:/app/logs# 按月日志+原始提示词持久化-/var/run/docker.sock:/var/run/docker.sock:ro# 如需在容器内起验证容器deploy:resources:limits:cpus:"2.0"# 三件套和3个工人的实测够用值memory:2g# 低于2g曾出现OOM，见踩坑restart:unless-stoppedhealthcheck:test:["CMD","uv","run","python","-c","import sqlite3;sqlite3.connect('/app/data/tickets.db').execute('SELECT 1')"]interval:60stimeout:10sretries:3dashboard:image:ai-pipeline:${TAG:-latest}command:uv run python-m ai_loop_course.dashboard--serve 8080env_file:.envvolumes:-./data:/app/data:ro# 看板只读挂载，只读分析不抢写锁-./logs:/app/logs:roports:-"8080:8080"restart:unless-stopped两个细节值得停一下。dashboard服务对data卷是只读挂载（:ro），这是第4节"只读分析别和写路径抢锁"的部署层落实——看板进程从物理上就写不了票据库。pipeline服务的memory限制2g是我用血泪换来的数字：3个并行工人每个要起pytest子进程，1g内存时OOM killer随机杀工人，票据全靠租约回收兜底，日志里全是worker w2 killed (OOM)。顺带一条经验：compose配置改动也要走和代码一样的评审。我有次随手把cpus从2.0改成4.0想"跑快点"，结果三个工人的pytest同时全速跑，磁盘IO被打满，整体反而慢了18%——资源限制是系统行为的一部分，改它就是改架构，这一条后来写进了上线检查清单的评审项里。docker compose up -d之后的状态：$ docker compose ps NAME STATUS PORTS ai-pipeline-1 Up 4 hours (healthy) ai-dashboard-1 Up 4 hours (healthy) 0.0.0.0:8080->8080/tcp $ docker compose logs pipeline --tail 5 ai-pipeline-1 | 2026-09-29 02:00:11 | INFO | pipeline | 定时任务启动，拉取到6个未处理Issue ai-pipeline-1 | 2026-09-29 02:14:33 | INFO | fix_worker | ✅ 票据#101完成 https://github.com/me/repo/pull/522 耗时95s ai-pipeline-1 | 2026-09-29 02:31:02 | INFO | notify | 日报已推送Slack #ai-pipeline 频道三、密钥注入：三种方案对比这条流水线要三个密钥：LLM的API key、GitHub token（开PR、读Issue）、Slack webhook。注入方案我全试过，对比列出来：方案做法优点缺点适用.env文件compose的env_file零额外组件、5分钟搞定密钥明文落盘在构建机单机自用Docker secrets/run/secrets/挂载不进环境变量、不落镜像单机Compose下收益有限Swarm集群Vault/云KMS启动时拉取集中轮换、审计、动态密钥多一个强依赖组件团队生产我最终选.env+三条铁律，原因很简单：这是单机项目，Vault的运维成本大于它的安全增益（第7节复盘会再谈这个"过度工程"判断）。三条铁律：# .env —— 永不进Git（.gitignore第一条就是它）ANTHROPIC_API_KEY=sk-ant-xxxxxxGITHUB_TOKEN=ghp_xxxxxxSLACK_WEBHOOK=https://hooks.slack.com/services/xxxx# 铁律1：仓库里只放模板 .env.example（值全为占位符）# 铁律2：代码里用pydantic-settings读环境变量，密钥永不硬编码# 铁律3：日志只打印key末6位（第1节日志规范），全文永不落盘配套的pydantic-settings校验，启动时密钥缺失直接fail fast：# src/ai_loop_course/config.pyfrompydantic_settingsimportBaseSettingsclassSettings(BaseSettings):"""部署配置：环境变量注入+启动时校验，缺密钥立刻报错不进主流程。"""anthropic_api_key:strgithub_token:strslack_webhook:strdb_path:str="data/tickets.db"model_config={"env_file":".env"}settings=Settings()# import即校验：任何密钥缺失，进程在第一行就死四、定时任务：cron/systemd/Actions三选一凌晨2点触发，三种方案真实对比过：维度宿主机cronsystemd timerGitHub Actions流水线跑在哪构建机容器构建机容器GitHub runner访问票据库✅本地SQLite✅本地SQLite❌要artifacts搬库定时精度分钟级分钟级常延迟5-15分钟崩溃通知自己写journalctl+unit配置✅邮件内置运维成本最低中（学unit语法）零（不在自己机器）关键分叉点是状态放哪：我的票据库和日志都在构建机本地，Actions的runner是每次全新的环境，把SQLite搬来搬去既慢又容易出竞态。所以主流水线选了systemd timer（比cron多了日志归集和失败重启），Actions只承担CI（lint+test+build镜像）——各干各擅长的事。# /etc/systemd/system/ai-pipeline.timer [Unit] Description=Run AI pipeline at 02:00 daily [Timer] OnCalendar=*-*-* 02:00:00 Persistent=true # 错过的触发（机器关机）开机后补跑 [Install] WantedBy=timers.target# /etc/systemd/system/ai-pipeline.service [Unit] Description=AI issue-to-PR pipeline [Service] Type=oneshot WorkingDirectory=/opt/ai-pipeline ExecStart=/usr/bin/docker compose run --rm pipeline TimeoutStartSec=3600 # 整条流水线1小时硬超时，防doom loop烧整夜CI侧的Actions工作流，build完直接SSH部署：# .github/workflows/ci.ymlname:cion:push:branches:[main]jobs:build:runs-on:ubuntu-lateststeps:-uses:actions/checkout@v4-run:uv sync--frozen&&uv run ruff check .&&uv run mypy src-run:uv run pytest tests/-q-run:docker build-t registry.local/ai-pipeline:${{github.sha}}.-name:deployuses:appleboy/ssh-action@v1with:host:${{secrets.DEPLOY_HOST}}username:deploykey:${{secrets.DEPLOY_SSH_KEY}}script:|cd /opt/ai-pipeline TAG=${{ github.sha }} docker compose pull pipeline dashboard TAG=${{ github.sha }} docker compose up -d# Actions一次完整CI的日志（节选） ruff check . ✓ 0 issues mypy src ✓ Success: no issues found in 18 source files pytest tests/ -q ✓ 41 passed in 12.3s docker build ✓ ai-pipeline:9c41f2b deploy via ssh ✓ compose up -d (healthy in 42s)五、版本升级与SQLite状态迁移升级最常见的翻车点：新版本代码期望的表结构变了，旧票据库里躺着老结构的票。我的方案是版本号+迁移脚本，SQLite下二十几行搞定：# src/ai_loop_course/migrate.py"""SQLite票据库迁移：按schema_version逐级升级，事务保证中途失败不损坏数据。"""importsqlite3 MIGRATIONS:dict[int,str]={# 版本N → 版本N+1的DDL；新增列用默认值兼容旧行1:"ALTER TABLE tickets ADD COLUMN lease_until INTEGER DEFAULT 0",2:"ALTER TABLE tickets ADD COLUMN cost_usd REAL DEFAULT 0.0",3:"CREATE INDEX idx_tickets_status ON tickets(status)",}defmigrate(db_path:str="data/tickets.db")->int:"""容器每次启动调用：建库（首次）→逐级执行迁移→写入当前版本。"""withsqlite3.connect(db_path)asconn:conn.execute("CREATE TABLE IF NOT EXISTS meta (key TEXT PRIMARY KEY, value TEXT)")row=conn.execute("SELECT value FROM meta WHERE key='schema_version'").fetchone()version=int(row[0])ifrowelse0forvinrange(version+1,len(MIGRATIONS)+1):# 从version+1逐级升，绝不跳级conn.execute(MIGRATIONS[v])conn.execute("INSERT OR REPLACE INTO meta VALUES ('schema_version', ?)",(str(v),))conn.commit()returnlen(MIGRATIONS)迁移脚本在容器入口处最先执行（CMD里第一步），配合这个纪律：迁移只加列不删列、新列必须有默认值、跳级禁止。升级时的数据流：$ TAG=9c41f2b docker compose up -d ai-pipeline-1 | 2026-09-29 03:10:01 | INFO | migrate | schema_version 2 → 3（新增status索引） ai-pipeline-1 | 2026-09-29 03:10:01 | INFO | pipeline | 租约回收：0张过期票 ai-pipeline-1 | 2026-09-29 03:10:01 | INFO | pipeline | 流水线就绪，等待02:00定时触发回滚方案写在部署脚本里：保留最近3个tag的镜像，healthcheck连续失败就TAG=上一个sha docker compose up -d。因为数据卷从不参与升级，回滚镜像=回到旧代码+同一个票据库，代码可回滚、状态只前进，这是有状态系统升级的安全底座。六、部署脚本、备份与恢复演练升级路径跑通之后，剩下的风险都藏在"万一"里：万一新镜像有bug、万一磁盘坏了、万一误删了票据库。三个万一对应三件事：回滚、备份、演练。部署动作本身也代码化，deploy.sh把"拉镜像→起容器→验健康→失败回滚"串成一条：#!/usr/bin/env bash# deploy.sh —— 一键部署+健康验证+自动回滚set-euopipefailSHA=$(gitrev-parse--shortHEAD)cd/opt/ai-pipelineTAG=$SHAdockercompose pull pipeline dashboardTAG=$SHAdockercompose up-dforiin$(seq19);do# 最多等90秒等healthysleep10STATUS=$(dockerinspect--format='{{.State.Health.Status}}'\"$(dockercomposeps-qpipeline)"2>/dev/null||echostarting)if["$STATUS"="healthy"];thenecho"$SHA">.last_good_tag# 记录好tag，供下次回滚echo"deploy$SHAok";exit0fidoneecho"health check failed, rolling back to$(cat.last_good_tag)"TAG=$(cat.last_good_tag)dockercompose up-dexit1备份走SQLite官方backup API——页级拷贝不阻塞写路径，凌晨3点的cron与流水线错峰：# scripts/backup_db.py"""SQLite在线备份：backup API不锁写路径，保留最近30份。"""importsqlite3,timefrompathlibimportPathdefbackup(src:str="data/tickets.db")->str:"""备份票据库到backups/，清掉30份之外的旧备份。"""dst=Path(f"backups/tickets-{time.strftime('%Y%m%d-%H%M')}.db")dst.parent.mkdir(exist_ok=True)withsqlite3.connect(src)ass,sqlite3.connect(dst)asd:s.backup(d)# 在线备份：主库写操作不被阻塞foroldinsorted(dst.parent.glob("tickets-*.db"))[:-30]:old.unlink()returnstr(dst)$ uv run python scripts/backup_db.py 备份完成：backups/tickets-20260929-0300.db（412KB，保留30份，最旧已清理） $ sqlite3 backups/tickets-20260929-0300.db "SELECT status, COUNT(*) FROM tickets GROUP BY status;" done|208 escalated|9备份不演练等于没有备份——我每月在备份副本上跑一次恢复演练，顺手校验行数和最新票据时间。灾备指标定下来并实测过：指标目标手段实测RPO 数据丢失上限≤24h每日3点备份+rclone异地满足RTO 恢复时长≤15min还原db+起容器演练8min回滚时长≤5mindeploy.sh自动实测3min部署脚本三条原则：幂等（重复执行结果一致，中途失败重跑即可）、有退路（每个危险动作前先记好回滚点，.last_good_tag就是证据）、有证据（成功失败都落日志）。这三条比脚本本身重要——脚本会换，原则不会。最后再回答一次"为什么不上K8s"：这套系统的全部有状态资产是一个SQLite文件加一个日志目录，单机+卷备份的RTO是8分钟，满足这条流水线的全部灾备要求。K8s带来的自动扩缩容、多节点高可用，对"每晚跑一次的批处理"是负资产——多一套控制面就多一个凌晨三点可能崩的东西。等第7节路线图里的多仓库、多语言真把负载推到单机极限，再迁移不迟。架构升级的触发器是真实负载，不是简历。七、上线检查、踩坑与监控值守7.1 上线前检查清单清单我每次发版前逐项打勾，全是真实事故换来的：## 上线检查清单 - [ ] 密钥不进Git（.env在.gitignore第一位，仓库历史里grep不到sk-前缀） - [ ] 镜像内无密钥（docker run --rm 镜像 env | grep -i key 为空） - [ ] 日志目录已挂载持久化（删容器后logs/loop-YYYY-MM.log仍在） - [ ] SQLite数据目录已挂载（tickets.db在宿主机） - [ ] 资源限制已配置（memory 2g，低于此值有OOM前科） - [ ] 健康检查端点可用（docker inspect看healthy状态） - [ ] 告警通知已配置（Slack发一条测试消息能收到） - [ ] 回滚方案已测试（上一个tag能一键up） - [ ] 备份策略已配置（每天cron备份tickets.db到异地） - [ ] 迁移脚本干跑通过（在库的副本上执行migrate()无报错）7.2 踩坑实录坑1：OOM杀工人。内存限制1g时3个并行工人+pytest子进程超了配额，OOM killer专挑占用最大的进程杀，恰好是正在干活的工人。现象很诡异：票据莫名回到pending，日志里只有kernel的kill记录。修复：memory提到2g，同时把pytest -p no:cacheprovider加进验证器命令，砍掉pytest缓存这个内存大户。容器内存限制必须用实测压出来，不是拍出来。坑2：容器时区UTC，定时跑错8小时。第一次上线systemd timer凌晨2点触发，容器内按UTC算成了上午10点，正好撞上我的开发时间，两拨进程同时写票据库。修复：compose加TZ=Asia/Shanghai环境变量+镜像装tzdata。定时系统和业务系统的时区必须显式声明，"默认时区"是分布式系统最老的坑之一。坑3：升级把票据库锁死在旧容器里。有次我把SQLite文件误放进镜像（COPY . .把data/一起拷了），两个容器各自拿着一份"票据库"，状态从此分叉。修复：.dockerignore加上data/和logs/，并且VOLUME声明兜底。状态只能活在卷里，镜像必须是纯函数。7.3 监控与值守：让沉默的失败自己喊出声healthcheck只管容器活没活，"跑完了但一张票都没处理"这种沉默失败要靠值守脚本盯着。为什么值守脚本不和流水线合在一个进程里？进程内检查有个盲区：流水线自己崩了，检查也跟着死。post_run由systemd独立拉起，流水线跑完跑一次、跑挂也跑一次——看门狗必须在被看护者的生命周期之外。# scripts/post_run.py"""值守检查：流水线结束后核对三件事——票清了没、产出有没有、钱超了没。"""fromai_loop_course.dashboardimportfetch_stats,fetch_costfromai_loop_course.notifyimportsend_slackfromai_loop_course.logging_configimportget_logger logger=get_logger("post_run")defpost_run(budget_usd:float=50.0)->None:"""沉默失败检测：正常退出但产出为零，比崩溃更危险。"""stats=fetch_stats()stuck=stats.get("running",0)+stats.get("pending",0)cost=sum(c["cost"]forcinfetch_cost().values())ifstuck:send_slack(f"🚨 流水线结束但有{stuck}张票未终态（工人崩溃或租约未回收）")ifstats.get("done_7d",0)==0andstats.get("pending",0)+stats.get("escalated",0)>0:send_slack("🚨 近7日完成数为0：流水线在空转，检查分诊与工人")ifcost>budget_usd:send_slack(f"🚨 本月LLM成本${cost:.2f}已超预算${budget_usd}，检查doom loop")logger.info(f"值守检查完成：积压{stuck}张，本月成本${cost:.2f}")2026-09-29 02:31:30 | INFO | post_run | 值守检查完成：积压0张，本月成本$13.57 2026-09-29 02:31:31 | INFO | notify | ✅ 日报已推送（无告警）值守的核心思想是给每种沉默失败配一句人话：“票没清完"翻译成"工人崩了或租约没回收”，“完成数为0"翻译成"在空转烧钱”，“成本超标"翻译成"该查doom loop了”。日志里这些是数字，Slack里必须是行动指令。值守告警的分级：级别触发条件通道期望响应P1票据库不可写/流水线空转Slack立即@当场处理P2积压票>10/成本超预算Slack普通消息当天处理P3单票三次失败升级日报汇总次日审阅这套值守体系最终改变的是我对"自动化"的定义。第一版我以为自动化=代码能跑；现在我认为自动化=失败时我能在10分钟内知道，且知道该做什么。第11章第6节讲通知与升级是无人值守的最后一公里，这张分级表就是那一节的落地。凌晨的系统不需要比我聪明，只需要比我先醒。小结镜像分层+非root+业务语义健康检查：依赖清单单独一层让缓存命中，USER runner收窄杀伤面，健康检查查票据库而不是ping端口。状态只在卷里：tickets.db和logs挂宿主机卷，看板只读挂载，代码可回滚、状态只前进，升级=换镜像+跑迁移。密钥铁律：.env永不进Git、pydantic-settings启动校验fail fast、日志只露key末6位。触发器选型跟着状态走：主流水线systemd timer（本地SQLite），CI交给Actions（无状态），各干各擅长的事。下节预告第13章前6节，从架构到部署全部走完。最后一节坐下来算总账：第13章第7节《项目复盘：踩坑清单与改进路线图》——按严重度排序的踩坑清单、值得保留的设计、过度工程的教训、最终量化成果，以及这个项目的下一步。如果觉得本文对你有帮助，欢迎点赞、收藏、关注三连！本系列持续更新中，关注不迷路~文章编号：第13章第6节 | 总进度：96/120 | 预计阅读时间：10分钟
第6节 部署：容器化与CI/CD集成一句话总结：Dockerfile与compose部署、密钥注入方案对比、定时任务（cron/systemd/Actions三选一）、版本升级与状态迁移；外加一份我每次上线前逐项打勾的检查清单。本文导航一、部署目标：换台机器十分钟跑起来二、容器化：Dockerfile与Compose三、密钥注入：三种方案对比四、定时任务：cron/systemd/Actions三选一五、版本升级与SQLite状态迁移六、部署脚本、备份与恢复演练七、上线检查、踩坑与监控值守小结一、部署目标：换台机器十分钟跑起来第5节结束时，流水线在我的开发机上已经跑得很漂亮了。但"在我机器上能跑"不是部署，部署的定义我给自己定得很硬：任何一台干净的Linux机器，装好Docker后十分钟内让流水线跑起来，且我的密钥从头到尾不落进任何Git仓库。这个目标拆开是四件事：容器化（环境标准化）、密钥注入（安全）、定时触发（无人值守）、状态迁移（升级不丢票）。整个交付链路：git push mainGitHub Actionslint+test+build镜像镜像仓库tag=git shaSSH到构建机docker compose pullcompose up -d滚动重启流水线数据卷不动tickets.db+logs保留健康检查失败自动回滚tag注意V那个节点：升级只换代码镜像，data/（SQLite票据库）和logs/（按月日志+原始提示词）挂在宿主机卷上，容器怎么重启都不丢。这个设计在第1节架构定稿时就埋下了——有状态的只有票据库，其他组件全部可抛弃，部署时这句架构原则直接兑现成docker volume。二、容器化：Dockerfile与Compose2.1 Dockerfile：分层缓存与非root直接上完整Dockerfile，每一层都有讲究：# Dockerfile FROM python:3.12-slim # 系统依赖：git是worktree必需，ca-certificates是HTTPS调用GitHub/LLM API必需 RUN apt-get update && apt-get install -y --no-install-recommends \ git ca-certificates \ && rm -rf /var/lib/apt/lists/* # 安装uv：从官方镜像拷贝二进制，不走pip COPY --from=ghcr.io/astral-sh/uv:latest /uv /usr/local/bin/uv WORKDIR /app # 第一层：只拷依赖清单，代码改动不触发依赖重装（缓存命中的关键） COPY pyproject.toml uv.lock ./ RUN uv sync --frozen --no-dev # --frozen：严格按lockfile，可复现 # 第二层：业务代码 COPY src/ src/ COPY pareto_config.yaml ./ # 非root运行：容器被攻破时少一层杀伤面 RUN useradd -m runner && chown -R runner:runner /app USER runner # 数据与日志目录：由compose挂载卷覆盖，这里只保证存在 VOLUME ["/app/data", "/app/logs"] # 健康检查：票据库可查=服务活着 HEALTHCHECK --interval=60s --timeout=10s --retries=3 \ CMD uv run python -c "import sqlite3; sqlite3.connect('/app/data/tickets.db').execute('SELECT 1 FROM tickets LIMIT 1')" || exit 1 CMD ["uv", "run", "python", "-m", "ai_loop_course.night_pipeline"]三个容易被忽略的点。分层顺序：依赖清单（pyproject.toml/uv.lock）单独一层放在代码前面，我改一行业务代码重新build时，依赖层直接命中缓存，构建从4分钟掉到25秒。非root：这条流水线会执行git操作和shell命令，容器逃逸的杀伤面必须收窄，加USER runner只要两行。HEALTHCHECK用业务语义：不是ping端口而是查票据库，"进程活着"和"系统可用"是两回事。构建与本地验证：# 构建镜像（tag用git短sha，部署和回滚都靠它）dockerbuild-tai-pipeline:$(gitrev-parse--shortHEAD).# 本地冒烟：跑一次分诊模块确认依赖齐、密钥能读到dockerrun--rm--env-file .env ai-pipeline:$(gitrev-parse--shortHEAD)\uv run python-mai_loop_course.triage_module--smoke[+] Building 24.7s (14/14) FINISHED => [internal] load build definition from Dockerfile => CACHED [deps 1/2] COPY pyproject.toml uv.lock ./ => CACHED [deps 2/2] RUN uv sync --frozen --no-dev ← 依赖层缓存命中 => [2/2] COPY src/ src/ => exporting to image ai-pipeline:9c41f2b Smoke test: triage_module 导入成功，pydantic模型校验通过，密钥已从环境变量读取（key=…f3a9c2）2.2 Compose：挂载、限流、健康检查单机部署用Compose足够（第1节选型表说过，K8s在这个规模是自虐）。完整配置：# docker-compose.ymlservices:pipeline:image:ai-pipeline:${TAG:-latest}# TAG由部署脚本注入git shaenv_file:.env# 密钥注入（见下一节）volumes:-./data:/app/data# SQLite票据库持久化-./logs:/app/logs# 按月日志+原始提示词持久化-/var/run/docker.sock:/var/run/docker.sock:ro# 如需在容器内起验证容器deploy:resources:limits:cpus:"2.0"# 三件套和3个工人的实测够用值memory:2g# 低于2g曾出现OOM，见踩坑restart:unless-stoppedhealthcheck:test:["CMD","uv","run","python","-c","import sqlite3;sqlite3.connect('/app/data/tickets.db').execute('SELECT 1')"]interval:60stimeout:10sretries:3dashboard:image:ai-pipeline:${TAG:-latest}command:uv run python-m ai_loop_course.dashboard--serve 8080env_file:.envvolumes:-./data:/app/data:ro# 看板只读挂载，只读分析不抢写锁-./logs:/app/logs:roports:-"8080:8080"restart:unless-stopped两个细节值得停一下。dashboard服务对data卷是只读挂载（:ro），这是第4节"只读分析别和写路径抢锁"的部署层落实——看板进程从物理上就写不了票据库。pipeline服务的memory限制2g是我用血泪换来的数字：3个并行工人每个要起pytest子进程，1g内存时OOM killer随机杀工人，票据全靠租约回收兜底，日志里全是worker w2 killed (OOM)。顺带一条经验：compose配置改动也要走和代码一样的评审。我有次随手把cpus从2.0改成4.0想"跑快点"，结果三个工人的pytest同时全速跑，磁盘IO被打满，整体反而慢了18%——资源限制是系统行为的一部分，改它就是改架构，这一条后来写进了上线检查清单的评审项里。docker compose up -d之后的状态：$ docker compose ps NAME STATUS PORTS ai-pipeline-1 Up 4 hours (healthy) ai-dashboard-1 Up 4 hours (healthy) 0.0.0.0:8080->8080/tcp $ docker compose logs pipeline --tail 5 ai-pipeline-1 | 2026-09-29 02:00:11 | INFO | pipeline | 定时任务启动，拉取到6个未处理Issue ai-pipeline-1 | 2026-09-29 02:14:33 | INFO | fix_worker | ✅ 票据#101完成 https://github.com/me/repo/pull/522 耗时95s ai-pipeline-1 | 2026-09-29 02:31:02 | INFO | notify | 日报已推送Slack #ai-pipeline 频道三、密钥注入：三种方案对比这条流水线要三个密钥：LLM的API key、GitHub token（开PR、读Issue）、Slack webhook。注入方案我全试过，对比列出来：方案做法优点缺点适用.env文件compose的env_file零额外组件、5分钟搞定密钥明文落盘在构建机单机自用Docker secrets/run/secrets/挂载不进环境变量、不落镜像单机Compose下收益有限Swarm集群Vault/云KMS启动时拉取集中轮换、审计、动态密钥多一个强依赖组件团队生产我最终选.env+三条铁律，原因很简单：这是单机项目，Vault的运维成本大于它的安全增益（第7节复盘会再谈这个"过度工程"判断）。三条铁律：# .env —— 永不进Git（.gitignore第一条就是它）ANTHROPIC_API_KEY=sk-ant-xxxxxxGITHUB_TOKEN=ghp_xxxxxxSLACK_WEBHOOK=https://hooks.slack.com/services/xxxx# 铁律1：仓库里只放模板 .env.example（值全为占位符）# 铁律2：代码里用pydantic-settings读环境变量，密钥永不硬编码# 铁律3：日志只打印key末6位（第1节日志规范），全文永不落盘配套的pydantic-settings校验，启动时密钥缺失直接fail fast：# src/ai_loop_course/config.pyfrompydantic_settingsimportBaseSettingsclassSettings(BaseSettings):"""部署配置：环境变量注入+启动时校验，缺密钥立刻报错不进主流程。"""anthropic_api_key:strgithub_token:strslack_webhook:strdb_path:str="data/tickets.db"model_config={"env_file":".env"}settings=Settings()# import即校验：任何密钥缺失，进程在第一行就死四、定时任务：cron/systemd/Actions三选一凌晨2点触发，三种方案真实对比过：维度宿主机cronsystemd timerGitHub Actions流水线跑在哪构建机容器构建机容器GitHub runner访问票据库✅本地SQLite✅本地SQLite❌要artifacts搬库定时精度分钟级分钟级常延迟5-15分钟崩溃通知自己写journalctl+unit配置✅邮件内置运维成本最低中（学unit语法）零（不在自己机器）关键分叉点是状态放哪：我的票据库和日志都在构建机本地，Actions的runner是每次全新的环境，把SQLite搬来搬去既慢又容易出竞态。所以主流水线选了systemd timer（比cron多了日志归集和失败重启），Actions只承担CI（lint+test+build镜像）——各干各擅长的事。# /etc/systemd/system/ai-pipeline.timer [Unit] Description=Run AI pipeline at 02:00 daily [Timer] OnCalendar=*-*-* 02:00:00 Persistent=true # 错过的触发（机器关机）开机后补跑 [Install] WantedBy=timers.target# /etc/systemd/system/ai-pipeline.service [Unit] Description=AI issue-to-PR pipeline [Service] Type=oneshot WorkingDirectory=/opt/ai-pipeline ExecStart=/usr/bin/docker compose run --rm pipeline TimeoutStartSec=3600 # 整条流水线1小时硬超时，防doom loop烧整夜CI侧的Actions工作流，build完直接SSH部署：# .github/workflows/ci.ymlname:cion:push:branches:[main]jobs:build:runs-on:ubuntu-lateststeps:-uses:actions/checkout@v4-run:uv sync--frozen&&uv run ruff check .&&uv run mypy src-run:uv run pytest tests/-q-run:docker build-t registry.local/ai-pipeline:${{github.sha}}.-name:deployuses:appleboy/ssh-action@v1with:host:${{secrets.DEPLOY_HOST}}username:deploykey:${{secrets.DEPLOY_SSH_KEY}}script:|cd /opt/ai-pipeline TAG=${{ github.sha }} docker compose pull pipeline dashboard TAG=${{ github.sha }} docker compose up -d# Actions一次完整CI的日志（节选） ruff check . ✓ 0 issues mypy src ✓ Success: no issues found in 18 source files pytest tests/ -q ✓ 41 passed in 12.3s docker build ✓ ai-pipeline:9c41f2b deploy via ssh ✓ compose up -d (healthy in 42s)五、版本升级与SQLite状态迁移升级最常见的翻车点：新版本代码期望的表结构变了，旧票据库里躺着老结构的票。我的方案是版本号+迁移脚本，SQLite下二十几行搞定：# src/ai_loop_course/migrate.py"""SQLite票据库迁移：按schema_version逐级升级，事务保证中途失败不损坏数据。"""importsqlite3 MIGRATIONS:dict[int,str]={# 版本N → 版本N+1的DDL；新增列用默认值兼容旧行1:"ALTER TABLE tickets ADD COLUMN lease_until INTEGER DEFAULT 0",2:"ALTER TABLE tickets ADD COLUMN cost_usd REAL DEFAULT 0.0",3:"CREATE INDEX idx_tickets_status ON tickets(status)",}defmigrate(db_path:str="data/tickets.db")->int:"""容器每次启动调用：建库（首次）→逐级执行迁移→写入当前版本。"""withsqlite3.connect(db_path)asconn:conn.execute("CREATE TABLE IF NOT EXISTS meta (key TEXT PRIMARY KEY, value TEXT)")row=conn.execute("SELECT value FROM meta WHERE key='schema_version'").fetchone()version=int(row[0])ifrowelse0forvinrange(version+1,len(MIGRATIONS)+1):# 从version+1逐级升，绝不跳级conn.execute(MIGRATIONS[v])conn.execute("INSERT OR REPLACE INTO meta VALUES ('schema_version', ?)",(str(v),))conn.commit()returnlen(MIGRATIONS)迁移脚本在容器入口处最先执行（CMD里第一步），配合这个纪律：迁移只加列不删列、新列必须有默认值、跳级禁止。升级时的数据流：$ TAG=9c41f2b docker compose up -d ai-pipeline-1 | 2026-09-29 03:10:01 | INFO | migrate | schema_version 2 → 3（新增status索引） ai-pipeline-1 | 2026-09-29 03:10:01 | INFO | pipeline | 租约回收：0张过期票 ai-pipeline-1 | 2026-09-29 03:10:01 | INFO | pipeline | 流水线就绪，等待02:00定时触发回滚方案写在部署脚本里：保留最近3个tag的镜像，healthcheck连续失败就TAG=上一个sha docker compose up -d。因为数据卷从不参与升级，回滚镜像=回到旧代码+同一个票据库，代码可回滚、状态只前进，这是有状态系统升级的安全底座。六、部署脚本、备份与恢复演练升级路径跑通之后，剩下的风险都藏在"万一"里：万一新镜像有bug、万一磁盘坏了、万一误删了票据库。三个万一对应三件事：回滚、备份、演练。部署动作本身也代码化，deploy.sh把"拉镜像→起容器→验健康→失败回滚"串成一条：#!/usr/bin/env bash# deploy.sh —— 一键部署+健康验证+自动回滚set-euopipefailSHA=$(gitrev-parse--shortHEAD)cd/opt/ai-pipelineTAG=$SHAdockercompose pull pipeline dashboardTAG=$SHAdockercompose up-dforiin$(seq19);do# 最多等90秒等healthysleep10STATUS=$(dockerinspect--format='{{.State.Health.Status}}'\"$(dockercomposeps-qpipeline)"2>/dev/null||echostarting)if["$STATUS"="healthy"];thenecho"$SHA">.last_good_tag# 记录好tag，供下次回滚echo"deploy$SHAok";exit0fidoneecho"health check failed, rolling back to$(cat.last_good_tag)"TAG=$(cat.last_good_tag)dockercompose up-dexit1备份走SQLite官方backup API——页级拷贝不阻塞写路径，凌晨3点的cron与流水线错峰：# scripts/backup_db.py"""SQLite在线备份：backup API不锁写路径，保留最近30份。"""importsqlite3,timefrompathlibimportPathdefbackup(src:str="data/tickets.db")->str:"""备份票据库到backups/，清掉30份之外的旧备份。"""dst=Path(f"backups/tickets-{time.strftime('%Y%m%d-%H%M')}.db")dst.parent.mkdir(exist_ok=True)withsqlite3.connect(src)ass,sqlite3.connect(dst)asd:s.backup(d)# 在线备份：主库写操作不被阻塞foroldinsorted(dst.parent.glob("tickets-*.db"))[:-30]:old.unlink()returnstr(dst)$ uv run python scripts/backup_db.py 备份完成：backups/tickets-20260929-0300.db（412KB，保留30份，最旧已清理） $ sqlite3 backups/tickets-20260929-0300.db "SELECT status, COUNT(*) FROM tickets GROUP BY status;" done|208 escalated|9备份不演练等于没有备份——我每月在备份副本上跑一次恢复演练，顺手校验行数和最新票据时间。灾备指标定下来并实测过：指标目标手段实测RPO 数据丢失上限≤24h每日3点备份+rclone异地满足RTO 恢复时长≤15min还原db+起容器演练8min回滚时长≤5mindeploy.sh自动实测3min部署脚本三条原则：幂等（重复执行结果一致，中途失败重跑即可）、有退路（每个危险动作前先记好回滚点，.last_good_tag就是证据）、有证据（成功失败都落日志）。这三条比脚本本身重要——脚本会换，原则不会。最后再回答一次"为什么不上K8s"：这套系统的全部有状态资产是一个SQLite文件加一个日志目录，单机+卷备份的RTO是8分钟，满足这条流水线的全部灾备要求。K8s带来的自动扩缩容、多节点高可用，对"每晚跑一次的批处理"是负资产——多一套控制面就多一个凌晨三点可能崩的东西。等第7节路线图里的多仓库、多语言真把负载推到单机极限，再迁移不迟。架构升级的触发器是真实负载，不是简历。七、上线检查、踩坑与监控值守7.1 上线前检查清单清单我每次发版前逐项打勾，全是真实事故换来的：## 上线检查清单 - [ ] 密钥不进Git（.env在.gitignore第一位，仓库历史里grep不到sk-前缀） - [ ] 镜像内无密钥（docker run --rm 镜像 env | grep -i key 为空） - [ ] 日志目录已挂载持久化（删容器后logs/loop-YYYY-MM.log仍在） - [ ] SQLite数据目录已挂载（tickets.db在宿主机） - [ ] 资源限制已配置（memory 2g，低于此值有OOM前科） - [ ] 健康检查端点可用（docker inspect看healthy状态） - [ ] 告警通知已配置（Slack发一条测试消息能收到） - [ ] 回滚方案已测试（上一个tag能一键up） - [ ] 备份策略已配置（每天cron备份tickets.db到异地） - [ ] 迁移脚本干跑通过（在库的副本上执行migrate()无报错）7.2 踩坑实录坑1：OOM杀工人。内存限制1g时3个并行工人+pytest子进程超了配额，OOM killer专挑占用最大的进程杀，恰好是正在干活的工人。现象很诡异：票据莫名回到pending，日志里只有kernel的kill记录。修复：memory提到2g，同时把pytest -p no:cacheprovider加进验证器命令，砍掉pytest缓存这个内存大户。容器内存限制必须用实测压出来，不是拍出来。坑2：容器时区UTC，定时跑错8小时。第一次上线systemd timer凌晨2点触发，容器内按UTC算成了上午10点，正好撞上我的开发时间，两拨进程同时写票据库。修复：compose加TZ=Asia/Shanghai环境变量+镜像装tzdata。定时系统和业务系统的时区必须显式声明，"默认时区"是分布式系统最老的坑之一。坑3：升级把票据库锁死在旧容器里。有次我把SQLite文件误放进镜像（COPY . .把data/一起拷了），两个容器各自拿着一份"票据库"，状态从此分叉。修复：.dockerignore加上data/和logs/，并且VOLUME声明兜底。状态只能活在卷里，镜像必须是纯函数。7.3 监控与值守：让沉默的失败自己喊出声healthcheck只管容器活没活，"跑完了但一张票都没处理"这种沉默失败要靠值守脚本盯着。为什么值守脚本不和流水线合在一个进程里？进程内检查有个盲区：流水线自己崩了，检查也跟着死。post_run由systemd独立拉起，流水线跑完跑一次、跑挂也跑一次——看门狗必须在被看护者的生命周期之外。# scripts/post_run.py"""值守检查：流水线结束后核对三件事——票清了没、产出有没有、钱超了没。"""fromai_loop_course.dashboardimportfetch_stats,fetch_costfromai_loop_course.notifyimportsend_slackfromai_loop_course.logging_configimportget_logger logger=get_logger("post_run")defpost_run(budget_usd:float=50.0)->None:"""沉默失败检测：正常退出但产出为零，比崩溃更危险。"""stats=fetch_stats()stuck=stats.get("running",0)+stats.get("pending",0)cost=sum(c["cost"]forcinfetch_cost().values())ifstuck:send_slack(f"🚨 流水线结束但有{stuck}张票未终态（工人崩溃或租约未回收）")ifstats.get("done_7d",0)==0andstats.get("pending",0)+stats.get("escalated",0)>0:send_slack("🚨 近7日完成数为0：流水线在空转，检查分诊与工人")ifcost>budget_usd:send_slack(f"🚨 本月LLM成本${cost:.2f}已超预算${budget_usd}，检查doom loop")logger.info(f"值守检查完成：积压{stuck}张，本月成本${cost:.2f}")2026-09-29 02:31:30 | INFO | post_run | 值守检查完成：积压0张，本月成本$13.57 2026-09-29 02:31:31 | INFO | notify | ✅ 日报已推送（无告警）值守的核心思想是给每种沉默失败配一句人话：“票没清完"翻译成"工人崩了或租约没回收”，“完成数为0"翻译成"在空转烧钱”，“成本超标"翻译成"该查doom loop了”。日志里这些是数字，Slack里必须是行动指令。值守告警的分级：级别触发条件通道期望响应P1票据库不可写/流水线空转Slack立即@当场处理P2积压票>10/成本超预算Slack普通消息当天处理P3单票三次失败升级日报汇总次日审阅这套值守体系最终改变的是我对"自动化"的定义。第一版我以为自动化=代码能跑；现在我认为自动化=失败时我能在10分钟内知道，且知道该做什么。第11章第6节讲通知与升级是无人值守的最后一公里，这张分级表就是那一节的落地。凌晨的系统不需要比我聪明，只需要比我先醒。小结镜像分层+非root+业务语义健康检查：依赖清单单独一层让缓存命中，USER runner收窄杀伤面，健康检查查票据库而不是ping端口。状态只在卷里：tickets.db和logs挂宿主机卷，看板只读挂载，代码可回滚、状态只前进，升级=换镜像+跑迁移。密钥铁律：.env永不进Git、pydantic-settings启动校验fail fast、日志只露key末6位。触发器选型跟着状态走：主流水线systemd timer（本地SQLite），CI交给Actions（无状态），各干各擅长的事。下节预告第13章前6节，从架构到部署全部走完。最后一节坐下来算总账：第13章第7节《项目复盘：踩坑清单与改进路线图》——按严重度排序的踩坑清单、值得保留的设计、过度工程的教训、最终量化成果，以及这个项目的下一步。如果觉得本文对你有帮助，欢迎点赞、收藏、关注三连！本系列持续更新中，关注不迷路~文章编号：第13章第6节 | 总进度：96/120 | 预计阅读时间：10分钟