Docker 自动化运维清单：部署、巡检、备份、日志和恢复

在主机选的后台技术交流中，经常遇到朋友抱怨 Ollama 跑着跑着内存溢出，或者 n8n 的流程数据因为没备份而丢失。Docker 虽然极大简化了 AI Agent 和自动化工具的部署，但“能跑起来”距离“稳定运行生产环境”还有很长的路要走。很多故障其实可以通过一份标准化的运维清单来避免。本文整理了一份涵盖部署、巡检、备份、日志和恢复的 Docker 自动化运维清单，帮助你在 VPS 上守住关键数据和服务稳定性。

Docker 自动化运维清单核心要素

使用 Docker Compose 规范化部署

不要在生产环境使用冗长的 `docker run` 命令，一旦容器重启或迁移，参数很难复现。所有的服务，包括 AI 模型、数据库、Web 服务，都应通过 `docker-compose.yml` 管理。这不仅能明确端口映射和卷挂载，还能方便地进行版本控制。

在编写 Compose 文件时，必须显式指定 `restart: unless-stopped` 策略，防止 VPS 重启后服务罢工。对于 AI Agent 类应用，务必加上 m_size` 参数，避免大模型加载时因共享内存不足崩溃。

yaml
services:
ollama:
image: ollama/ollama:latest
container_name: ollama
restart: unless-stopped
ports:
– "11434:11434"
volumes:
– ollama_data:/root/.ollama
environment:
– OLLAMA_KEEP_ALIVE=-1 # 保持模型加载，减少响应延迟
deploy:
resources:
reservations:
devices:
– driver: nvidia
count: 1
capabilities: [gpu]

定时巡检脚本与健康检查

容器状态不代表服务健康。Web 服务可能返回 500，数据库可能死锁，但 Docker 进程依然在运行。不能只依赖 `docker ps`。建议编写简单的 Shell 脚本，结合 `curl` 或 `wget` 对关键接口进行探活，并利用 Cron 定时执行。

基础的巡检命令应包含资源占用查看和僵尸进程清理：

docker stats –no-stream

docker system prune -f

对于核心业务，建议在 Compose 文件中配置 `healthcheck`，让 Docker 引擎自动监控并重启异常容器。

卷与配置文件的自动化备份

这是最容易被忽视的一环。VPS 硬盘损坏或误删容器是常态。备份的核心是数据卷和配置文件，而不是镜像本身。镜像丢了可以重新拉取，数据丢了就是灾难。

对于 AI Agent 的知识库、n8n 的数据库以及 ChatGPT-Next-Web 的配置，建议使用 `tar` 配合 Cron 进行每日增量或全量备份。

#!/bin/bash
BACKUP_DIR="/opt/backups"
DATE=$(date +%Y%m%d_%H%M%S)
mkdir -p $BACKUP_DIR

docker run –rm \
-v n8n_data:/data \
-v $BACKUP_DIR:/backup \
alpine tar czf /backup/n8n_data_$DATE.tar.gz -C /data .

注意：不要直接备份 `/var/lib/docker` 目录，这通常需要停止 Docker 服务，且恢复时极易出现版本兼容性问题。

防止磁盘被日志写满

Docker 默认的日志驱动是 `json-file`，如果不加限制，日志文件会无限增长，直到把 VPS 磁盘撑满，导致所有服务宕机。这个坑在跑流式输出的 AI 工具时尤其常见。

必须在 `/etc/docker/daemon.json` 中配置全局日志上限，或者在 Compose 文件中针对单个服务配置。

json
{
"log-driver": "json-file",
"log-opts": {
"max-size": "10m",
"max-file": "3"
}
}

修改后记得执行 `systemctl daemon-reload` 和 `systemctl restart docker` 生效。

快速恢复与故障排查

当服务挂掉时，别急着重装系统。先看日志。使用 `docker logs –tail 100 <container_name>` 查看最近的报错信息。如果是 OOM（内存不足），需要检查是否给 AI 模型分配了过多资源；如果是权限错误，检查 UID/GID 映射。

恢复数据时，只需在新的 Compose 配置中挂载之前备份的卷或解压备份文件即可。

docker run –rm \
-v n8n_data:/data \
-v $BACKUP_DIR:/backup \
alpine sh -c "cd /data && tar xzf /backup/n8n_data_20231027.tar.gz"

老鸟叮嘱

1.别用 Root 跑所有服务：尽量在 Dockerfile 或 Compose 中指定 `USER`，避免容器被攻破后直接获得宿主机 Root 权限。
2.敏感数据别进环境变量：API Key、数据库密码不要直接写在 `docker-compose.yml` 里。使用 `.env` 文件并将其加入 `.gitignore`，或者使用 Docker Secrets（如果是 Swarm 模式）。
3.端口不要裸露公网：Redis、Postgres 等中间件端口严禁映射到 0.0.0.0，只映射到 127.0.0.1 或使用 Docker Network 内部通信。
4.AI 工具吃内存：部署本地大模型前，先用 `free -h` 确认物理内存和 Swap 空间，否则 SSH 可能会卡死。

FAQ

Q1：Docker 容器重启后数据会丢失吗？
A：如果没有使用数据卷或绑定挂载，容器内部写入 `/var` 等目录的数据在删除容器后会丢失。务必将重要数据（如数据库、知识库）挂载到宿主机指定目录或命名卷中。

Q2：如何批量更新所有 Docker 镜像？
A：可以使用 `docker run –rm -v /var/run/docker.sock:/var/run/docker.sock containrrr/watchtower –cleanup –run-once` 命令，或者编写脚本遍历 `docker images | awk '{print $1}'` 进行 pull 和 recreate。

Q3：为什么我的 AI 容器启动立刻退出？
A：通常是启动命令错误或依赖服务未就绪。先用 `docker logs` 查看报错。如果是因为依赖数据库，可以加上 `depends_on` 并配合 `wait-for-it` 脚本确保启动顺序。

Q4：Docker 占用磁盘空间太大怎么清理？
A：使用 `docker system df` 查看占用分布。优先清理 `docker system prune -a` 删除未使用的镜像和容器。注意，`build cache` 也会占用大量空间，构建失败时记得清理。

Q5：生产环境可以用 Watchtower 自动更新吗？
A：对于 API 变化频繁的 AI 工具（如 Ollama 或 WebUI），自动更新可能导致不兼容。建议先在测试环境验证，或设置定时通知而非自动更新。

Q6：如何限制某个容器的 CPU 和内存使用？
A：在 `docker-compose.yml` 的 `deploy` 资源限制下配置 `limits`。例如限制内存使用不超过 2G：`mem_limit: 2g` 或 `reservations`/`limits` 组合。

这份清单覆盖了从容器创建到灾难恢复的全过程，虽然增加了前期的配置工作量，但能极大减少后期半夜起来救火的次数。运维的本质就是将不确定性通过规范转化为确定性。