专栏进度：03 / 03 (Docker 专题收官)
在本地跑通 Docker Compose 只是开始。当你把代码推向生产服务器时，你必须面对现实世界的残酷：服务器重启了怎么办？数据库数据被容器删了怎么办？手动部署太慢怎么办？
一、 持久化存储：给容器一个“不失忆”的硬盘
容器的生命周期是短暂的（Ephemeral）。默认情况下，容器一旦被删除，内部产生的所有数据（如上传的用户头像、日志）都会随之消失。
方案：Named Volumes (命名卷)
在 docker-compose.yml 中，不要直接映射路径，建议使用命名卷：
YAML
services:
db:
image: postgres:15
volumes:
– postgres_data:/var/lib/postgresql/data # 挂载到命名卷
volumes:
postgres_data: # 声明卷，它受 Docker 管理，不会随容器删除而消失
二、 健康检查（Healthcheck）：拒绝“僵尸容器”
有时候容器进程虽然在运行，但内部的 Python 应用因为内存溢出或数据库连接断开已经“假死”了。
实战配置：让 Docker 自动监控应用状态
YAML
services:
web:
build: .
healthcheck:
test: [“CMD”, “curl”, “-f”, “http://localhost:8000/health”] # 访问健康检查接口
interval: 30s # 每30秒检查一次
timeout: 10s # 10秒不响应视为失败
retries: 3 # 连续失败3次后标记为 unhealthy
提示：配合容器编排工具（如 Docker Swarm 或 K8s），当检查失败时，系统会自动重启该容器。
三、 自动化流水线：CI/CD 的丝滑体验
不要再用 FTP 传文件或者登录服务器手动 git pull 了！最专业的做法是：代码推送到 GitHub/GitLab -> 自动触发构建 -> 自动推送到镜像仓库 -> 服务器自动拉取重启。
GitHub Actions 核心逻辑示例：
Build: 在云端执行 docker build。
Push: 将镜像推送到阿里云或 Docker Hub。
Deploy: 通过 SSH 告诉生产服务器：docker-compose pull && docker-compose up -d。
四、 生产环境的安全“金律”
禁用 Root 用户：在 Dockerfile 中通过 USER 指令切换到非特权用户。
限制资源使用：在 Compose 中限制 CPU 和内存，防止某个容器内存泄露拖垮整台服务器。
YAML
deploy:
resources:
limits:
cpus: ‘0.5’
memory: 512M
最小化镜像：生产环境严禁使用 python:3.9（约 900MB），必须使用 -slim 或 -alpine（约 50-100MB）。
