Container Manager 上手：从镜像到容器

从 Docker 到 Container Manager

DSM 7.2 之后，群晖把原来的 Docker 套件正式更名为 Container Manager。这次更名不只是换了个图标：底层 Docker 引擎升级到了 24.x，界面重新设计，还新增了「项目」标签页，可以直接在图形界面里跑 docker-compose。原来的容器和镜像在升级后会原样保留，旧教程里的大多数操作也只是换了个入口位置而已。

对已经熟悉 DSM 基本操作的玩家来说，需要转变的观念只有一个：Container Manager 就是 Docker。Docker Hub 上的文档、docker run 命令、compose 文件在这里统统适用，你只是在「翻译界面」而不是「学习新产品」。如果更习惯命令行，也可以开启 SSH 直接用 docker 命令操作，和图形界面是完全等价的入口。

在开始之前，先确认两件事：第一，你的机型支持 Container Manager，J 系列入门型号和部分 Value 型号不提供该套件，套件中心搜不到就是不支持；第二，内存最好在 4 GB 以上，DSM 本身大约占用 1~2 GB，剩下的才是容器能用的空间。后台常驻十来个轻量容器，6 GB 是比较舒服的起点。

新装的 NAS 建议先做一项准备：在 File Station 里建一个共享文件夹 docker，专门存放所有容器的配置和数据。好处有三：权限可以统一授予某个用户、数据集中在一个地方方便整体备份、目录路径短且整齐。养成习惯后，/volume1/docker/应用名/ 就是你在这台 NAS 上所有容器的家。

界面总览：七个标签页各管什么

打开 Container Manager，左侧一列标签页就是它的全部功能。先记住每个标签页的分工，后面会少走很多弯路。

标签页 作用 使用场景
概览 显示运行中的服务和资源占用 平时可以忽略
容器 列出全部容器，也可用向导新建 单个容器的增删改查
镜像 本地镜像库，提示可更新版本 更新前先来这里下载
注册表 搜索并拉取 Docker Hub 镜像 找新应用时用
网络 管理 Docker 网络 配置自定义网桥
项目 图形化运行 docker-compose 多容器编排主力
日志 套件自身的事件日志 排查启动失败

老玩家最容易忽略的是「项目」标签页。DSM 7.2 之前要用 compose 必须登录 SSH 敲命令，现在直接粘贴 YAML 就能起一整套服务，本栏目的后续文章会大量用到它。

拉取第一个镜像

以注册表拉取镜像为例，流程很简单：

  1. 打开「注册表」标签页，在搜索框输入应用名，比如 uptime-kuma。
  2. 找到带「Official Image」标记或下载量很高的条目，双击。
  3. 在弹出的标签列表里选一个版本。追新功能选 latest，求稳定选具体版本号，生产环境建议固定版本，方便回滚。
  4. 等待下载完成，「镜像」标签页里就会出现它。

选镜像有一条经验：越是热门的项目，镜像维护越勤快，文档也越完善。冷门镜像不是不能玩，但出问题时要自己读 Dockerfile 的心理准备要先有。

创建容器：向导走一遍

在「镜像」标签页里选中一个镜像，点击「运行」，就会进入容器创建向导。向导分常规、卷、端口、环境几个步骤，其中最关键的是下面三项。

两种网络模式对比

第一项是网络模式。Bridge 是默认模式，容器拿到独立内网 IP，需要手动映射端口；Host 模式直接共享 NAS 的 IP，不用映射端口，但容易和 DSM 自身服务抢端口。

网络模式 是否要映射端口 适用场景
Bridge 是 绝大多数应用
Host 否 需要 mDNS 发现的设备类应用
自定义 macvlan 否 想给容器分配局域网独立 IP

第二项是卷映射，也就是目录挂载。容器是临时的，删掉容器它内部的数据就没了，所以配置文件和数据一定要映射到 NAS 的真实目录上。比如把 /volume1/docker/uptime-kuma 映射到容器内的 /app/data。这一步的详细玩法和权限坑，单独有一篇展开。

第三项是端口映射。本地端口填 NAS 上空闲的高位端口，容器端口填应用文档里写的端口。注意避开 DSM 自己占用的 80、443、5000、5001、8080，比如把应用的 80 映射到本地的 8081。

向导的高级设置里还有几项值得留意。「自动重启」建议勾上，NAS 重启后容器会自己回来；「资源限制」可以给容器封顶内存，防止个别应用吃光整机资源；「权限」里通常保持默认即可，除非文档明确要求特权模式。这些设置在容器建好之后还能再改，不用一次想清楚。

向导步骤 关键设置 建议值
常规 容器名称 应用名，便于识别
网络 端口映射 本地高位端口避开 8080
卷 文件或文件夹 /volume1/docker/应用名
环境 TZ Asia/Shanghai
高级 自动重启 勾选

容器创建向便流程

从单容器到项目：向导的局限

向导建单个容器很顺手，但服务一多就捉襟见肘。一个很典型的例子是带数据库的应用：向导要分别建两个容器，再手动指定网络让对方互通，改了一次端口就要两边一起改。这种时候「项目」标签页就派上用场了，它把一整套服务的网络、端口、卷、依赖关系写进同一个 YAML 文件，一次部署、一键重建。

两种方式的分工很明确：临时试用一个新镜像，用向导快点看效果；打算长期运行的服务，尤其是两个以上容器配合的，一律写成项目。向导建出来的容器最终也能导出成配置，不如直接从 YAML 起步来得干净。项目这块的完整玩法见本系列的编排章节。

启动之后的例行检查

容器跑起来不等于万事大吉，养成三个小习惯：

一是在「容器」标签页里看状态是不是「运行中」，CPU 和内存曲线有没有异常飙升。二是点进容器详情看日志，应用启动时报的错一般都写在里面，数据库连不上、配置目录不可写这类问题日志里都有明示。三是在浏览器里实际访问一次端口，确认功能正常。

如果容器反复重启，最先怀疑三件事：端口被占用、配置目录权限不对、环境变量写错了。日志里通常会有明确的报错行，对照修改即可。想看容器到底占了哪些资源，也可以 SSH 上去用命令行排查。

端口与资源的长期规划

玩容器是会上瘾的，半年后你会发现 NAS 上跑了二十多个服务。所以从第一个容器开始就做两件事：一是建立统一的目录结构，所有容器配置都放在 /volume1/docker/<应用名>/ 下面，重装系统或者整机迁移时一把拷走，两分钟就能恢复全部服务；二是记录端口分配表，哪怕只是备忘录里几行字，记下「8081 给了 Uptime Kuma、8096 给了 Jellyfin、3000 给了镜像站」，半年后新建容器时你会感谢自己。网络知识扎实的读者，还可以顺便了解一下容器网络与局域网的关系，入门概念可参考 计算机网络基础。

容器的日常操作

容器跑稳之后，日常要做的操作就那么几样。在「容器」列表里右键某个容器，可以启动、停止、重启和删除；点容器名进详情，能实时看日志和资源曲线。要改配置的话，停止容器后点「编辑」即可，改完重新启动生效。唯独要注意：删除容器会把容器内部没映射出去的数据一并删掉，操作前先确认卷映射已经覆盖了所有重要目录。

端口冲突是最常见的一类问题，日志里一般会出现「端口已被占用」字样，换一个本地端口就能解决；其次是权限问题，表现是容器反复重启、日志里一串「拒绝访问」，这需要回头检查映射目录的归属，属于下一篇要展开的权限话题。

日志是排错的第一现场。点开容器详情的「日志」标签，默认显示最近的输出，右上角可以筛选级别。容器启动失败、应用连不上数据库、配置文件解析报错，这些信息都会原样写进日志，配合 命令行速查 里的排查手法，大多数问题都能自己定位。

另一个值得常用的是「镜像」标签页的更新提示。有新版本可用时镜像条目旁会出现提示，但 Container Manager 没有内置自动更新，更新流程要手动走：先下载新镜像，再停止容器、编辑容器把镜像版本切到新的、重新启动。更新的具体策略和回滚手法，在「容器自启、更新与资源限制」一篇里详细展开。

延伸阅读