第2章 环境准备：Docker基础、Kubernetes概念、CI/CD工具选型
说实话，很多做AI的同学一上来就撸模型，觉得环境配置是"运维的事"。但我在一线踩过太多坑——模型在笔记本上跑得飞起，一上生产就崩，十有八九是环境不一致闹的。这一章咱们就把地基打牢，聊聊Docker、Kubernetes和CI/CD工具怎么选、怎么搭。
2.1 Docker 基础——模型打包的第一道关
Docker 说白了就是"轻量级虚拟机"，但比虚拟机快得多。我习惯把模型、依赖、环境配置全塞进一个镜像里，这样不管在开发机还是生产集群上，跑起来一模一样。
核心概念：镜像（Image）是只读模板，容器（Container）是运行实例。你想想看，镜像就像类，容器就是对象。
写 Dockerfile 有几个坑，我刚开始也犯过：
- 层数别太多——每一条 RUN 都会产生一层，层多了镜像又大又慢。我习惯用
&&把命令串起来。 - 多阶段构建——编译环境和运行环境分开。比如训练好的模型，用 Python 3.9-slim 做最终镜像，能小一半。
- .dockerignore——把
.git、__pycache__这些扔进去，不然构建上下文能把你气哭。
举个栗子，一个简单的模型服务 Dockerfile：
# 第一阶段：安装依赖
FROM python:3.9-slim as builder
WORKDIR /app
COPY requirements.txt .
RUN pip install --user -r requirements.txt
# 第二阶段：运行
FROM python:3.9-slim
WORKDIR /app
COPY --from=builder /root/.local /root/.local
COPY ./model /app/model
COPY ./serve.py /app/
ENV PATH=/root/.local/bin:$PATH
CMD ["python", "serve.py"]
💡 避坑指南：我曾经把整个虚拟环境打包进镜像，结果镜像 2.3GB，部署一次等十分钟。后来改用多阶段构建，直接缩到 400MB。
2.2 Kubernetes 概念——从单机到集群
K8s 这东西，刚接触时觉得概念一堆，其实核心就几个：Pod（最小调度单元）、Deployment（声明式更新）、Service（网络抽象）。我个人习惯把模型推理服务封装成 Deployment，再用 Service 暴露端口。
为什么需要 K8s？你想想看，如果只有一个模型实例，挂了就全完了。K8s 能自动重启、扩容、负载均衡。我在项目中遇到过流量突增，HPA（水平自动伸缩）直接拉起 10 个 Pod，稳得很。
几个关键资源：
| 资源 | 作用 | 模型场景举例 |
|---|---|---|
| Pod | 运行容器的最小单位 | 一个 Pod 跑一个模型推理服务 |
| Deployment | 管理 Pod 的声明式更新 | 模型版本升级，滚动更新 |
| Service | 提供稳定的网络入口 | ClusterIP 对内，NodePort 对外 |
| ConfigMap | 存储非敏感配置 | 模型路径、超时参数 |
| Secret | 存储敏感信息 | 数据库密码、API Key |
| HPA | 根据 CPU/内存自动扩缩 | 推理请求量突增时自动加副本 |
⚠️ 注意：别把模型文件直接塞进镜像里，尤其是大模型（几个G那种）。我建议用 PVC（持久卷）挂载，或者用对象存储（S3/MinIO）动态拉取。
2.3 CI/CD 工具选型——找到你的那把刀
CI/CD 工具多如牛毛，但适合多模型流水线的其实就那几款。我根据实战经验，给你列个对比：
| 工具 | 优势 | 劣势 | 适合场景 |
|---|---|---|---|
| Jenkins | 插件生态丰富，老牌稳定 | 配置重，维护成本高 | 已有 Jenkins 基础设施的团队 |
| GitLab CI | 与 GitLab 深度集成，.gitlab-ci.yml 简洁 | 依赖 GitLab 平台 | 代码和 CI/CD 在同一平台 |
| Argo Workflows | K8s 原生，DAG 编排强，适合多模型并行 | 学习曲线稍陡 | 复杂多模型流水线、K8s 重度用户 |
我个人习惯怎么选？
- 如果团队小、追求轻量，GitLab CI 最省事——一个
.gitlab-ci.yml搞定构建、测试、部署。 - 如果流水线复杂，比如同时训练 5 个模型、做 A/B 测试、然后灰度发布，Argo Workflows 的 DAG 编排简直神器。
- Jenkins 嘛……除非你公司已经重度依赖它，否则我不太推荐新项目入坑。配置 Jenkinsfile 的酸爽，谁用谁知道。
我的建议：先拿 GitLab CI 快速跑通 MVP，等流水线复杂到需要并行 DAG 时，再迁移到 Argo Workflows。别一开始就上重武器。
举个例子，一个简单的 GitLab CI 流水线，包含模型训练和镜像构建：
stages:
- train
- build
- deploy
train_model:
stage: train
script:
- python train.py --model bert
artifacts:
paths:
- models/
build_image:
stage: build
script:
- docker build -t registry.example.com/bert:latest .
- docker push registry.example.com/bert:latest
deploy:
stage: deploy
script:
- kubectl set image deployment/bert bert=registry.example.com/bert:latest
💡 避坑指南：我曾经在 GitLab CI 里直接写
docker build，结果 runner 没权限连 docker daemon。后来改用 docker:dind 服务容器，或者用 kaniko 在无特权模式下构建，才搞定。
嗯，环境准备这块就聊到这儿。记住一句话：环境一致性是流水线的命根子。Docker 保证"在哪跑都一样"，K8s 保证"跑得稳、能伸缩"，CI/CD 保证"改完自动跑"。这三板斧抡好了，后面模型部署就是水到渠成的事。