Container Manager 与 Virtual Machine Manager：群晖上跑 Docker 和虚拟机的正确姿势
先搞清楚一件事：Docker 不是虚拟机
很多 NAS 新手的第一误区，是把 Docker 当成”轻量虚拟机”。这个理解会让后面一堆配置变得莫名其妙。
| 容器（Docker） | 虚拟机（VMM） | |
|---|---|---|
| 隔离层 | 共享宿主机内核 | 独立内核，完整虚拟化 |
| 启动速度 | 秒级 | 几十秒到几分钟 |
| 资源占用 | 很低 | 较高，要预留固定资源 |
| 能否跑非 Linux | 不能 | 能（Windows、Linux 各发行版） |
| 能否改内核参数 | 不能 | 能 |
| 迁移性 | 强，镜像通用 | 弱，镜像和平台绑定紧 |
判断准则就一条：如果你只是想跑一个服务（网站、数据库、下载工具、影音套件），用容器。如果你需要一个完整的操作系统环境，才用虚拟机。
群晖上 90% 的需求是前者。
Container Manager：DSM 7.2 之后的变化
Docker 套件在 DSM 7.2 之后更名为 Container Manager，界面和功能都有调整。
主要变化：
| 项目 | 老 Docker 套件 | Container Manager |
|---|---|---|
| 项目（Compose）支持 | 较弱 | 一等公民，界面直接编辑 YAML |
| 镜像仓库管理 | 简单 | 更完善，支持多 registry |
| 网络管理 | bridge 为主 | 界面能看到 macvlan 等网络 |
| 日志 | 简陋 | 有独立的日志面板 |
还有一个重要变化：不再支持 Node.js v14/v16 和旧版 PHP，这条是在 DSM 7.3 里砍掉的，会波及一些依赖旧运行时的第三方套件。
项目模式（Docker Compose）才是正确用法
群晖界面里可以直接点”容器→创建单个容器”，但我强烈建议用项目（Project）模式。
原因：
1. 可复现。配置写在 YAML 里，重装系统后一行命令就能跑回来 2. 便于迁移。同一份 compose 文件可以贴在任何支持 Docker 的设备上 3. 管理集中。一个项目的所有容器、网络、卷一目了然 4. 便于备份。compose 文件本身就是文档
一个标准的 compose 示例
version: "3.8"
services:
jellyfin:
image: jellyfin/jellyfin:latest
container_name: jellyfin
restart: unless-stopped
environment:
- TZ=Asia/Shanghai
- PUID=1026
- PGID=100
volumes:
- /volume1/docker/jellyfin/config:/config
- /volume1/docker/jellyfin/cache:/cache
- /volume1/media:/media:ro
devices:
- /dev/dri:/dev/dri
ports:
- 8096:8096
network_mode: bridge几点说明：
restart: unless-stopped比always更合理，手动停了不会自动重启PUID/PGID用 SSH 执行id 用户名查/dev/dri是硬件转码的关键，只有 Intel 核显机型才有- 媒体目录
:ro只读挂载，防止容器内程序误删源文件
目录布局建议
强烈建议在共享文件夹下建立统一的 docker 目录：
/volume1/docker/
├── jellyfin/
│ ├── config/
│ └── cache/
├── nginx/
│ └── config/
└── compose/
└── jellyfin.yml这样做的好处：
- Hyper Backup 只要备份 docker 目录就覆盖了所有容器配置
- 迁移时整个目录打包带走
- 权限统一处理，不会出现到处找文件的情况
注意：不要把容器配置散落在各个随机目录，也不要直接放在 volume1 根下。
网络模式怎么选
这是群晖 Docker 最容易踩坑的地方。
| 模式 | 特点 | 适用场景 |
|---|---|---|
| bridge（默认） | 容器在独立网段，通过端口映射访问 | 绝大多数场景 |
| host | 容器直接用宿主机网络栈 | 需要大量端口、或需要广播发现的服务 |
| macvlan | 容器获得局域网独立 IP | 需要容器像独立设备一样出现在局域网 |
默认建议用 bridge。简单、安全，出问题容易排查。
什么时候用 macvlan？
典型场景：你想跑一个服务，它需要在局域网里被自动发现（比如某些 DLNA 服务器、Home Assistant 的设备发现），或者你不想做一堆端口映射。
macvlan 的两个已知坑：
1. 宿主机和容器之间无法直接通信（这是 macvlan 协议的固有限制），解决方法是用专门的 workaround 或增加一条 host 网络 route 2. 群晖重启后偶尔出现网络不通，需要重启容器或重建网络
所以对新手：除非明确知道为什么需要 macvlan，否则不要用。
更新容器的正确流程
群晖界面上有”更新”按钮，但更稳妥的做法：
1. 先看清楚容器是否正在占用重要数据 2. 检查目标镜像的更新日志（尤其是 major version 变更） 3. 把 compose 文件里的 tag 改明确，不要用 latest 盲目追新 4. 拉取新镜像 → 重建容器（UI 里的”重置”或 compose 的 up -d） 5. 确认服务起来了再把旧镜像删掉
关于 latest 标签：方便，但危险。生产环境（哪怕是家庭的生产环境）建议锁定主版本号，比如 jellyfin/jellyfin:10.9，然后手动决定何时升。
Virtual Machine Manager：什么时候才该用
VMM 是群晖基于 KVM 的虚拟机套件，DSM 7 之后的版本功能已经比较完整。
适合用虚拟机的场景：
- 需要跑 Windows（跑个国产软件、老版 Office）
- 需要完整 Linux 发行版做开发测试
- 需要改内核、加载特殊模块
- 需要跑完整发行版做开发、编译、内核实验
- 做软路由（OpenWrt）
不适合用虚拟机的场景：
- 只是想跑个服务 → 用容器
- 老旧入门机型 → 根本跑不动
机型适配的真实情况
VMM 对硬件有要求，不是所有群晖都能跑：
| 建议 | 机型 |
|---|---|
| 可以跑 | Plus 系列（DS225+、DS425+、DS725+、DS925+、DS1525+ 等）、XS 系列、部分机架机型 |
| 勉强能跑 | 老 Plus（DS920+、DS1621+ 等），跑一两个轻量 VM |
| 别碰 | J 系列（ARM CPU，不支持 VMM） |
内存是第一瓶颈。跑一个 Windows 虚拟机，给 4GB 内存是比较合理的起点，而很多群晖机型出厂只有 2GB 或 4GB。
所以虚拟机用户的第一笔投资通常是：加内存 + 加 SSD。
关于 SSD：
- 虚拟机磁盘一定要放在 SSD 存储池上，放机械盘会慢到无法使用
- 有 M.2 槽的机型，建议用两条 NVMe 做 RAID 1 存储池专门放虚拟机
- 没有 M.2 的机型，可以考虑用 SATA SSD 替换一块盘位
两者的搭配建议
典型的家庭/小办公室组合：
| 层 | 技术 | 例子 |
|---|---|---|
| 基础设施 | Container Manager | Nginx 反向代理、DDNS、监控（Uptime Kuma） |
| 服务层 | Container Manager | Jellyfin、Home Assistant、数据库、下载工具 |
| 特殊需求 | VMM | Windows 跑特定软件、OpenWrt 软路由 |
| 存储 | NAS 共享文件夹 | 通过 NFS/SMB 挂载给容器或 VM |
一个实用技巧：用 Nginx Proxy Manager（容器）做统一入口 + 群晖申请 Let’s Encrypt 证书，这样所有服务都能用 https://xxx.你的域名 访问，不用记一堆端口号。
资源控制的经验值
给容器和虚拟机设限制，避免一个服务失控拖垮整个 NAS：
| 资源 | 建议 |
|---|---|
| 容器内存限制 | 按服务文档建议值 ×1.5，不要不设限 |
| 虚拟机内存 | 固定分配，不要过度承诺（overcommit） |
| CPU 限制 | 家庭环境一般不用设，但下载类容器建议限一下 |
| 总资源占用 | 给 DSM 自己留至少 1~2GB 内存 |
群晖的资源监控面板在 Resource Monitor 里，养成偶尔看一眼的习惯。
备份策略
这是最容易被跳过但最重要的一环：
容器要备份的是两部分：
1. 配置文件（docker/xxx/config 目录）→ 纳入 Hyper Backup 2. compose 文件本身 → 建议放在 NAS 上并有版本管理，甚至可以放一份到 Git
虚拟机要备份：
- VMM 有快照功能，做操作前打快照
- 整机导出可以做冷备
- 更重要的是 Hyper Backup 里勾选 VMM 相关目录
记住原则：容器和虚拟机里不要存任何不可重建的数据。所有重要数据都应该通过挂载卷放在 NAS 的共享文件夹里，这样它天然享受你配置的备份和快照保护。
常见故障速查
| 现象 | 常见原因 | 处理 |
|---|---|---|
| 容器起来就退出 | 配置有误或端口冲突 | 看日志，先查 compose 里的端口是否被占用 |
| 无法访问服务 | 端口未映射、防火墙 | 检查 ports 配置和 DSM 防火墙 |
| 容器内无法写文件 | 权限不匹配 | 查 PUID/PGID，或给目录加 Everyone 权限测试 |
| 硬件转码不生效 | 设备未映射或 CPU 不支持 | 确认 /dev/dri 存在且 CPU 有核显 |
| macvlan 容器失联 | macvlan 协议限制 | 换回 bridge，或增加 host route |
| VMM 无法启动 | 机型不支持或 BIOS 虚拟化未开 | 查官方兼容性列表 |
