Docker Compose怎样用tmpfs挂载临时目录

如果服务只需要缓存、临时解压目录或一次请求的中间文件，Docker Compose 的 tmpfs 比命名卷更合适：它把目录放在内存中，容器停止、重启或宿主机重启后内容不会保留。需要先记住一点，tmpfs 不是“更快的持久盘”，而是一块有明确生命周期的临时空间。

官方地址：https://docs.docker.com/compose/

先判断：这个目录真的可以丢吗

把目录改成 tmpfs 前，先问一句：容器被重新创建后，业务能否从数据库、对象存储或镜像重新得到这些文件？如果答案是否定的，就应该使用 named volume 或 bind mount。缩略图缓存、临时压缩包、渲染中间文件通常可以放进 tmpfs；订单附件、数据库文件和需要断点续传的文件不应该放进去。

在服务中声明 tmpfs 挂载

操作入口可以理解为“项目工作区 → compose.yaml → 目标服务 → 存储挂载”。下面给一个只给图片处理服务提供临时目录的例子。YAML 中的中文注释说明了每个关键字段的用途。

services:
  image-worker:
    image: example/image-worker:1.0
    # 临时文件放在容器内存中，容器删除后不会保留
    tmpfs:
      - /var/cache/image:rw,noexec,nosuid,size=256m,mode=1770
    # 给服务设置整体内存边界，tmpfs 用量也会计入该边界
    mem_limit: 768m

这里的挂载点是容器内的 /var/cache/image。rw 允许服务写入，noexec 防止把临时目录当作可执行文件目录，nosuid 不接受 setuid 权限，size=256m 限定临时盘大小，mode=1770 保留目录的组协作权限并避免普通用户随意删除他人文件。

如果只需要最简单的临时目录，也可以写成下面这样；但省略参数就等于把容量和权限边界交给默认值，生产服务最好把关键限制写出来。

services:
  report-worker:
    image: example/report-worker:1.0
    # 仅用于可重新生成的报告中间文件
    tmpfs:
      - /tmp/report-cache

启动后查看挂载状态

保存配置后，按“项目工作区 → 服务状态 → 启动”执行：

# 只启动示例服务，并在后台运行
docker compose up -d image-worker

# 查看 Compose 识别到的服务状态
docker compose ps image-worker

# 进入容器检查挂载点；df 的结果只用于观察临时文件系统
docker compose exec image-worker df -h /var/cache/image

# 查看该目录是否可写；测试文件随后立即删除
docker compose exec image-worker sh -c 'touch /var/cache/image/.probe && rm /var/cache/image/.probe'

界面说明图里应看到三类信息：服务处于运行状态、挂载点指向目标目录、存储类型标记为临时内存盘。命令输出的容量不是宿主机磁盘剩余空间；它反映的是这个挂载点的内存上限或运行时可用空间。

内存上限与生命周期要一起设计

tmpfs 的便利之处也是它的边界：数据驻留在内存中，空间使用会受到容器内存配置影响。size=256m 是挂载点的局部限制，mem_limit: 768m 是服务整体内存限制，二者不能当成两块独立可无限叠加的空间。应用自身的堆、线程栈和其他缓存也需要留出余量。

生命周期上，docker compose restart、docker compose down 或重新创建服务后，都不应假设 tmpfs 文件仍然存在。若程序启动时需要目录，可以让入口脚本创建目录；若目录中的内容需要恢复，则应把恢复来源放到持久化卷或外部对象存储。

services:
  image-worker:
    image: example/image-worker:1.0
    # 临时空间只存可重新生成的内容，避免误把业务数据当缓存
    tmpfs:
      - /var/cache/image:rw,noexec,nosuid,size=256m
    # 为进程和 tmpfs 共同设置可接受的内存总量
    mem_limit: 768m

常见问题

tmpfs 能不能代替 volume？

不能。tmpfs 解决的是临时数据和内存访问，volume 解决的是跨容器生命周期保存数据。选择标准是数据能否被安全丢弃，而不是目录读写速度。

tmpfs 的 size 写得越大越好吗？

不是。过大的上限会挤占服务和宿主机的内存预算，应该根据临时文件峰值、并发量和应用本身的内存需求留出余量。

tmpfs 适合存放密钥吗？

tmpfs 不会自动让数据变成“安全存储”。如果是敏感配置，应使用 Compose secrets 或其他受控注入方式；tmpfs 只描述文件的存储介质和生命周期。

为什么服务重启后缓存没了？

这是 tmpfs 的预期行为。需要保留的内容应迁移到 named volume、bind mount 或外部存储，并让缓存逻辑支持冷启动。

最终可以把判断压缩成一句话：能重新生成、只在服务运行期间有用的目录，用 tmpfs；需要跨重启、跨重建保留的数据，用持久化存储。这样配置后，tmpfs 才不会从性能优化变成隐蔽的数据丢失点。