企业官网建设流程全解析

容器在飞牛fnOS的Docker界面里还好好的，装完1Panel再打开一看，列表空了，数据是不是全没了？我前几天刚亲手折腾完这个问题，先说结论安抚一下：绝大多数情况下容器根本没丢，只是“看不见了”，恢复起来没想象中玄学。这篇文章把整个排查和恢复过程拆开讲，包括为什么会出现这个现象、怎么在SSH里把容器重新拉回面板、以及之后怎么避免再踩第二次坑。

动手之前先立个认知：飞牛fnOS、1Panel、Docker这三者，真正管数据的是Docker守护进程，两个面板都只是“看数据的眼睛”。眼睛花了，不代表仓库里的货没了。搞懂这条底层逻辑，后面所有的操作都不会慌。

1. 先搞清楚：容器“消失”到底是怎么发生的

1.1 飞牛fnOS的Docker到底是什么

飞牛fnOS本质上是Debian 12做底层，在外面套了一层NAS化的管理界面。系统自带的Docker应用并不是fnOS自己另写了一套容器运行时，而是把宿主机里的Docker Engine包装了一下，做成可视化操作面板。容器真正跑在系统里，数据落在/var/lib/docker或者你自定义的数据根目录，fnOS界面通过/var/run/docker.sock这个本地socket去和守护进程通信，再把你看到的容器列表渲染出来。

这里有个关键点：面板只是客户端，数据在宿主机。容器不会因为某个面板暂时不显示就凭空消失，除非有人改了Docker的数据根目录配置，或者把守护进程给换掉了，再或者手动执行过清理命令。理解这一点之后，遇到“容器消失”的第一反应不应该是重装、重置，而是先查状态。

在飞牛fnOS里，系统自带的Docker应用一般会在系统盘上运行，数据根目录默认是/var/lib/docker。如果你在fnOS的设置里改过Docker的数据存储路径，比如把它指到了某个存储空间的大分区上，那么这个自定义路径就写进了/etc/docker/daemon.json。这个文件非常关键，后面所有恢复操作都绕不开它。

1.2 1Panel安装时动了什么

1Panel是开源Linux服务器管理面板，Docker容器管理只是它的功能之一，不是全部。它的安装脚本有一个典型的逻辑：先检测系统里有没有可用的Docker环境，如果检测到/var/run/docker.sock存在且能正常通信，就复用现有的Docker；如果检测不到，才会自动安装一套docker-ce。

飞牛fnOS系统自带Docker，所以正常来说1Panel不会装出第二套Docker运行时。那容器为什么还会“消失”？根据我的排查经验，常见的有这么几种：

第一种，数据根目录被切换过。你之前可能为了让Docker数据不占系统盘，在fnOS或命令行里把>systemctl status docker docker info | grep -A2 "Docker Root Dir" cat /etc/docker/daemon.json 2>/dev/null docker ps -a docker volume ls

systemctl status docker确认Docker服务是否在运行。很多“容器消失”的根源就是服务根本没起来，面板连守护进程都连不上，肯定一片空白。

docker info | grep -A2 "Docker Root Dir"输出当前守护进程使用的数据根目录。如果你记忆中的数据在/var/lib/docker，但这里显示的是/vol1/docker，那就说明数据目录被切换过，容器没丢，只是换了个地方存放。

cat /etc/docker/daemon.json直接看配置文件内容，确认>docker ps -a --format "table {{.Names}}\t{{.Status}}\t{{.Image}}"

这个命令会把容器名、状态、镜像按表格列出来。重点看Status是不是Exited。只要容器都在这，只是停掉了，直接执行：

docker start $(docker ps -aq)

解释一下，docker ps -aq中-a表示显示所有容器，-q表示只输出容器ID，组合起来就是“所有容器的ID列表”，喂给docker start就能一次全部启动。启动完再执行docker ps确认所有容器恢复为Up状态。

这一步如果解决了，说明“容器消失”只是Docker重启后容器没自动拉起。根源往往是创建容器时没设置重启策略。顺手给重要容器补上：

docker update --restart=unless-stopped <容器名>

unless-stopped与always的区别是：前者在你手动停止容器后不会自动拉起来，后者无论什么情况都会拉起。对数据库这类敏感服务，unless-stopped更稳妥，避免你主动停库维护时又被系统反复拉起。

3.2 第二步：数据目录被换掉时，怎么把旧容器找回来

如果docker ps -a也看不到旧容器，但你在/var/lib/docker/containers下能看到一堆64位哈希命名的文件夹，基本可以确定是>rsync -av /vol1/docker/ /var/lib/docker/

这里有个必须强调的细节：如果旧目录本身就是完整的data-root结构，里面有containers、overlay2、volumes等子目录，那么应该把它整体合并过去。如果旧目录只是你为某个容器建的挂载文件夹，里面没有这几个Docker核心子目录，那就不要执行上面的命令，因为根本就不是一回事。

合并之前先干跑一次：

rsync -avn /vol1/docker/ /var/lib/docker/

-n表示试运行，只输出会拷贝哪些文件，不实际执行。确认无误后再去掉-n正式执行。合并完启动Docker，docker ps -a验证。

迁移过程中如果提示磁盘空间不足，先检查目标分区剩余空间，别硬迁。空间不够的情况下，优先保留containers和volumes两个子目录，这两个是最核心的数据资产。overlay2是镜像层，丢了最多重新拉镜像，代价可控。

3.3 第三步：在1Panel里把容器状态同步回来

当容器在SSH里已经能正常列出、也能启动了，回到1Panel界面，会出现两种结果：

第一种，容器出现在列表里，只是状态显示Exited。那直接在1Panel容器页面勾选并点击启动就行。

第二种，1Panel列表还是空的。这时候要检查它读Docker的方式。1Panel默认通过/var/run/docker.sock连接宿主机Docker，如果这个socket存在且权限正确，理论上不会读不到容器。在1Panel的容器页面找一找是否有刷新按钮或Docker状态指示，如果显示“连接正常”，多半是视图过滤问题，切换一下“全部容器”视图就能看到。

有一点特别容易引起误会：fnOS自带Docker界面创建的容器和1Panel创建的容器，在标签体系上不是一套代码。fnOS容器会带它自己平台的label，1Panel也会给自己的容器打label。当你用1Panel查看fnOS创建的容器时，有些容器旁边没有Compose标识、没有项目归属，看起来像是“外来户”，但这完全不影响管理和运行。容器就是容器，谁创建的不重要，Docker守护进程不会因为label不同就区别对待。

如果你以后想用1Panel统一管理，可以给旧容器补上1Panel期望的标签。但我个人认为没必要，因为1Panel的容器页面默认展示所有容器，标签缺失只是显示层面的小别扭，不影响功能。

4. 如果容器元数据真丢了，怎么用数据卷重建

4.1 怎么判断数据卷还在不在

恢复过程中有一种更复杂的情况：容器确实看不到了，containers目录也空了，但之前的挂载卷和镜像还在。这种情况下容器本身无法“找回”，但数据可以，重建容器即可恢复服务。

先判断资产还剩多少：

docker images docker volume ls

docker images列出所有镜像，如果镜像还在，重建就简单了，直接用原镜像启动新容器。docker volume ls列出所有数据卷，只要卷在，最核心的数据就在。

这里说一下Docker的数据存放逻辑。容器运行产生的数据分两类：一类写在容器可写层，容器删除就没了；另一类通过-v或--mount挂载到宿主机或数据卷，这部分独立于容器生命周期存在。所以只要当初创建容器时用了命名数据卷或bind mount，容器没了数据也不会丢。

如果当初没有挂载任何卷，数据全在容器可写层，那容器删除后就真的很难恢复了。这也提醒一件事：数据库、配置文件、上传目录这些价值高的数据，一定不要放在容器可写层，要挂出来。

4.2 用runlike和config.v2.json找回启动参数

如果你运气好，容器没有彻底删除，只是守护进程不认了，那/var/lib/docker/containers/<容器ID>/config.v2.json这个文件里记录了容器的完整启动配置。这个文件是Docker用来恢复容器元数据的核心，包括环境变量、端口映射、挂载关系、重启策略全都在里面。

想快速生成重建命令，可以用runlike这个工具：

pip install runlike runlike <容器名>

这个工具会读取容器的实际配置，输出一条完整的docker run命令，能直接拿来创建容器。不过runlike依赖Docker API能读到容器，也就是容器必须还在docker ps -a里。如果容器彻底消失了，就只能手动翻阅config.v2.json，把关键字段提取出来。

提取的时候重点看这么几个字段：

• Config.Env：环境变量，数据库的账号密码、应用配置基本都在这
• HostConfig.PortBindings：端口映射
• MountPoints：挂载点，重建时最不能错的就是这一块
• Config.Image：镜像名和tag
• HostConfig.RestartPolicy：重启策略

config.v2.json是JSON格式，用python3 -m json.tool config.v2.json格式化后再看，别直接cat，不然一堆转义字符看不清。

4.3 重建容器时挂载卷的正确姿势

有了启动参数，重建容器时最关键的步骤就是正确挂载数据卷。这里最容易出错的是把卷挂错位置。比如原来的数据库容器是把mysql_data卷挂到/var/lib/mysql，重建时挂到了/var/lib/mysql2，数据对社会在，但应用找不到，启动就是失败的。

推荐的做法是先用原参数创建一个同名的“临时容器”，但不启动它：

docker create --name temp_container <原参数...>

然后用docker inspect temp_container查看它是否与旧容器的挂载关系一致，确认无误后，删掉临时容器，再正式创建并启动。

重建时选择命名数据卷还是bind mount，取决于你的数据量和使用习惯。命名数据卷的好处是Docker统一管理，迁移方便；bind mount的好处是路径直观，用rsync备份方便。如果原来用bind mount，就保持bind mount，原来用命名卷，也保持命名卷，不要随意切换，否则路径一变，应用里的配置也得跟着改，容易产生连锁错误。

5. 常见问题与排查技巧实录

5.1 容器回来了，但fnOS界面还是空的

这是我实际操作中遇到最多的后续问题：SSH里容器明明跑着，1Panel也能看到，飞牛fnOS自带的Docker界面还是显示“暂无容器”。

原因还是在fnOS的标签体系。fnOS的Docker应用默认按“项目”分组展示，项目信息来自它自己的标签。你用命令行创建的容器，或者用1Panel创建的容器，没有fnOS的标签，就不会被归入任何项目，列表看起来就是空的。

解决办法有几个：第一，在fnOS的Docker应用里找到“刷新”或“设置”入口，重新加载一次容器列表；第二，如果还不行，在fnOS界面里重启Docker服务，注意这个操作会影响所有容器，确认当前业务可以中断再动；第三，接受现状，以命令行或1Panel为管理入口，把fnOS界面当成辅助参考。

我个人是推荐第三种方案的，因为fnOS界面本来就不是为跨平台容器管理设计的，强行让它识别所有容器反而增加复杂度。

5.2 启动容器时提示端口占用或设备不存在

容器恢复后启动，最常见的报错是端口占用：

Error response from daemon: driver failed programming external connectivity on endpoint ... Bind for 0.0.0.0:xxx failed: port is already allocated

说明当前有另一个进程或其他容器占了同一个端口。排查步骤：

netstat -tlnp | grep <端口号> docker ps -a | grep <端口号>

确认是谁在占用。如果是另一个容器占用了，说明新旧容器同时在跑，要先停掉重复的那个；如果是主机上的系统进程，比如nginx占了80端口，那就修改容器的端口映射，换一个宿主机端口重新创建。

还有一种情况是迁移data-root后，容器启动时找不到默认网桥。可以执行：

docker network ls docker network inspect bridge | grep -i subnet

网络配置混乱时，不建议手动去重置iptables，那会影响宿主机所有容器的对外通信。更稳妥的做法是把异常容器断开旧网络，重启Docker服务，再让容器重新接入。

5.3 面板提示“当前未设置服务器地址”

1Panel的面板设置里有一个“服务器地址”选项，它主要用于一些绑定服务、通知回调等功能，跟你恢复Docker容器没有直接关系。如果在恢复过程中看到“当前未设置服务器地址，请先在面板设置中设置!”这个提示，可以直接忽略，Docker管理的读写不依赖这个地址。

等你容器全部恢复完，再进1Panel的“设置”页面，把面板访问域名或服务器IP填上即可。这个地址不影响容器的启动、停止、日志查看等基础操作，不用被它干扰判断。

5.4 关键避坑清单

综合几次折腾，我把最容易被反复踩的坑整理成清单：

• 不要在没有做任何诊断之前执行docker system prune、docker volume prune。这些命令会清理未被使用的资源，等删完再发现容器“真没了”就晚了。
• 不要同时启动两套Docker管理环境去抢同一个docker.sock。fnOS界面和1Panel共用同一个守护进程没问题，但如果你手动再启动一个dockerd实例，socket会冲突，容器列表会彻底混乱。
• 修改data-root前，一定先确认新目录空间充足，并且牢记旧目录路径。改完必须重启Docker，重启后立刻用docker info验证。
• 创建容器时养成设置restart=unless-stopped的习惯，否则宿主重启后容器全处于Exited状态，面板上一片“消失”，纯属自己吓自己。
• 1Panel如果安装时发现没有Docker，会自动装一套docker-ce，这可能与系统已有的Docker产生冲突。安装前先确认已有Docker且能正常通信，避免出现两套运行时互相干扰的局面。

5.5 多个面板共存的管理建议

飞牛fnOS、1Panel、Portainer这些工具本质都是Docker的“前台”，同时安装本身没问题。但管理上建议只让一个面板作为日常主力，其他的作为辅助查看。多个面板对容器都做了自己的标签标注，偶尔会互相“看不见”对方的容器，这不是故障，只是标签体系不同。

我目前的习惯是：命令行作为最终裁决工具，1Panel作为日常管理主力，fnOS自带Docker界面只用来快速看资源占用和基本状态。这样既能发挥各个工具的长处，也不会因为面板之间的信息差产生太多困惑。恢复数据这种场景，最终靠的都是SSH和几个基础命令，面板只是锦上添花。

再分享一个细节：容器恢复后，最好顺手在1Panel里给关键容器补上资源限制和日志轮转配置。比如--log-opt max-size=50m --log-opt max-file=3，防止某个服务的日志文件无限增长把系统盘挤爆。这个操作虽然和“恢复”无关，但经历过一次数据目录被塞满导致的诡异故障后，你就会明白日志轮转有多重要。