外观
为什么在 NAS 上用容器
读完这篇，你能判断一个应用该不该用容器，知道容器的数据该放在哪，也能在 OMV 的三种容器方案里选出适合自己的那一种。
容器是什么
- 镜像（image）：别人把一个应用和它依赖的库打成的一个包。
- 容器（container）：用镜像跑起来的一个实例。它有自己的进程、文件系统和网络，看起来像一台独立的小机器。
- 卷（volume）与绑定挂载（bind mount）：把容器外面的目录接进容器里。容器被删掉重建时，接进去的目录还在，应用的配置和数据就放在这里。
- 端口映射：把容器里的某个端口接到 NAS 的某个端口上，浏览器才能访问到它。
容器和虚拟机不一样：它共用 NAS 的内核，不带完整的操作系统，所以启动快、占用小，但隔离没有虚拟机深。另外镜像分 CPU 架构，OMV 8 只有 amd64 和 arm64，选镜像时要确认它支持你的架构。
为什么官方建议用容器
OMV 官方文档的态度很明确：额外的软件，强烈建议用 Podman 或 Docker 跑容器。原因是以前出过很多事，软件版本更新带来了互相冲突的依赖，让 OMV 或那个软件没法用。插件只是为了方便才存在。
| 直接装在 OMV 上 | 容器 | 虚拟机 | |
|---|---|---|---|
| 依赖冲突 | 可能把 OMV 弄坏 | 依赖打在镜像里，不碰系统 | 完全独立 |
| 资源占用 | 最小 | 很小，共用内核 | 大，要给整套系统 |
| 升级 | 和系统更新绑在一起 | 拉新镜像，重建容器 | 单独升级 |
| 隔离程度 | 没有 | 进程、文件、网络隔离 | 最强 |
| 在 OMV 上怎么做 | 插件或 apt | Compose 插件 | KVM 插件 |
对 NAS 来说，容器还有两个实际的好处：
- 好迁移：一个 compose 文件加几个数据目录，拷到另一台机器就能接着跑。
- 好备份：配置和数据集中在几个目录里，备份这些目录就行。数据库类应用要多一步，见更新与备份容器。
不是什么都适合容器
要和内核、磁盘、用户体系深度打交道的功能，用 OMV 自己的功能或插件：RAID、ZFS、mergerfs、SMB、UPS（NUT）、WireGuard 等。判断标准见插件还是容器。
容器的数据放哪
这是用容器最重要的一个决定，装完再改要搬数据。推荐的做法来自 omv-extras wiki 的《Docker in OMV 8》：
| 内容 | 放在哪里 | 为什么 |
|---|---|---|
compose 文件（.yml、.env） | 共享文件夹 appdata，由插件管理 | 插件会自己生成，别手改 |
| 应用的配置和数据库 | appdata 下按应用分子目录 | 放在 SSD 上，应用更快 |
| 大数据：媒体、照片、文档 | 单独的共享文件夹 | 可以同时用 SMB 共享，也方便单独备份 |
| Docker 自己的数据：镜像、卷、日志 | 共享文件夹 docker，放在独立的盘 | 避免撑满系统盘；重装 OMV 时不受影响 |
| 插件的计划备份 | 共享文件夹 backup_compose | 最好和上面几项不在同一块盘 |
几条要点：
- 别把 Docker 的数据放在系统盘上，尤其是 U 盘或 SD 卡：Docker 持续写入，即使装了 writecache 也会折寿；放在系统盘上还可能把根目录撑满。wiki 建议 Docker 所在的盘至少 60–100 GB，大型媒体库再多留一些。
- Docker 的目录优先用 EXT4。不要放进 mergerfs 池，也不要放在 NTFS 上。
- 共享文件夹的名字可以自己取，本站统一用
appdata、data、backup_compose、docker。怎么建见安装 Docker 与 Compose 插件。
三条路：Compose、Podman、Kubernetes
| 方案 | 来源 | 引擎 | 适合 |
|---|---|---|---|
Compose 插件（openmediavault-compose） | omv-extras | Docker | 绝大多数应用。网上的 compose 文件可以直接参考，插件自带约两百个示例（截至 2026-10-23 为 197 个） |
Podman 插件（openmediavault-podman） | 官方 | Podman | 查看官方容器类插件（FileBrowser、PhotoPrism 等）用的容器，不是用来部署你自己的应用 |
Kubernetes 插件（openmediavault-k8s） | 官方 | K3s，单节点 | 想学 Kubernetes，或者想用官方 recipes |
新手选 Compose 插件，本章余下的文章都以它为准。后两者的定位见官方容器方案：Podman 与 Kubernetes 插件。
几个必须知道的事
容器的权限，就是它运行用户的权限
容器里的程序能读写哪些文件，取决于它以哪个用户（UID 和 GID）运行。如果把容器映射成 root，容器里的程序一旦被攻破，攻击者拿到的就是整台 NAS 的权限。属于 docker 组的用户同样等价于 root。
- 删容器不等于删数据，但只限于映射出来的目录。容器里没映射的部分，随容器一起消失。
- 端口映射默认对整个局域网开放，而且 OMV 防火墙的规则通常管不到它，见写好 compose 文件。
- 别混装 Docker：Compose 插件装的是 Docker 官方源的
docker-ce。不要再用apt手装 Debian 自带的docker.io，二选一。 - 官方不支持把 OMV 装进 LXC 容器里；在虚拟机里装 OMV，再在里面跑 Docker 是可以的。
检查结果
读完后你应该能回答这四个问题，回答不上来就先别动手：
- 这个应用的配置和数据，会放在哪个共享文件夹？
- 容器用哪个用户写这些目录？
- 备份会写到哪块盘？
- 更新出问题时，怎么退回去？
常见问题
容器会比直接装慢吗？ CPU 和内存上差别很小。真正影响速度的是数据所在的盘：数据库和缓存放机械盘会明显慢，所以配置目录尽量放 SSD。
我已经用 apt 装了软件，要迁到容器吗？ 不强制。但以后升级出问题时，容器的退路更清楚。迁移前先备份，并核对数据格式是否兼容。
NAS 重启后容器会自己起来吗？ 插件示例里的 restart: unless-stopped 会让它在 Docker 启动后自动起来。没起来时见重启后容器没起来。