小项目部署：Docker 还是直接跑在宿主机上

一、先看资源开销

在小规格机器上，这个差别很实际：

| 项目 | 直接跑 | Docker |

|---|---|---|

| 基础内存 | 0 | dockerd 约 50-100 MB |

| 镜像磁盘 | 0 | 基础镜像几百 MB 起 |

| 启动时间 | 毫秒级 | 秒级（容器初始化） |

| 隔离性 | 无 | 进程/网络/文件系统隔离 |

在 1 核 1G 的机器上，dockerd 那 100 MB 可能就是压垮骆驼的最后一根稻草。

二、什么时候 Docker 明显更划算

**依赖复杂时。** 比如你的服务需要特定版本的 Python + 一堆系统库 + 特定版本的 ffmpeg。直接装容易污染宿主机，版本冲突排查起来很痛苦。

Docker 把依赖打包进镜像，换机器直接跑，不会出现「在我这能跑」。

**需要多版本共存时。** 同一台机器跑两个 Python 版本的服务，用容器最干净。

**需要快速回滚时。** 镜像带 tag，出问题 `docker run` 上一个版本即可。

三、什么时候直接跑更好

**单文件脚本、依赖很少。** 一个 Python 脚本只用标准库，装 Docker 纯属增加复杂度。

**需要直接访问硬件或系统资源。** 虽然可以挂载，但配置麻烦。

**机器规格很小。** 省下的内存很关键。

四、折中方案

其实还有中间路线：

1. **venv + systemd**：Python 项目用虚拟环境隔离依赖，systemd 管进程。开销几乎为零，隔离性够用。

2. **静态编译**：Go/Rust 项目编译成单文件，直接扔上去跑。

3. **podman**：无守护进程，rootless，开销比 Docker 小。

我的实际选择：小机器上跑 Python 服务，用 **venv + systemd**。既避免了依赖污染，又没有额外开销。

五、如果决定用 Docker，几个优化

FROM python:3.12-slim
# 用 slim 而不是完整版，体积小很多

WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
# --no-cache-dir 避免镜像里留 pip 缓存

COPY . .
CMD ["python", "main.py"]

运行时限制资源：

docker run -d \
  --name myapp \
  --restart unless-stopped \
  --memory 256m \
  --cpus 0.5 \
  myapp:1.0

`--memory` 和 `--cpus` 很重要，防止单个容器吃满整机。

六、日志别忘

Docker 默认把日志写进 json-file，不加限制会无限增长：

docker run -d \
  --log-opt max-size=10m \
  --log-opt max-file=3 \
  myapp:1.0

我就见过容器日志把磁盘写满导致整机不可用的情况。

小结

判断标准很简单：**依赖复杂度 vs 资源余量**。依赖复杂且资源充足 → Docker；依赖简单或资源紧张 → 直接跑。不要为了「看起来专业」而上容器。