DPanel：把 Docker 日常管理搬进浏览器

一台家用服务器上的容器越来越多以后，最费时间的往往不是第一次执行 docker run，而是之后的日常动作：哪个容器正在重启、端口映射到哪里、某次拉取为什么失败、Compose 文件又存在哪个目录。DPanel 为这些操作提供中文网页界面，并直接连接 Docker Engine 完成容器、镜像、网络、存储卷和 Compose 管理。

这种方便有明确代价。DPanel 需要访问 Docker Socket，这项权限足以创建高权限容器、挂载宿主机目录并改变现有工作负载。DPanel 适合放在受控管理网络中，不能按普通只读监控面板的方式暴露到公网。下文先看 DPanel 能替代哪些命令行操作，再用 Community Edition Lite 完成一次只监听本机的部署和容器生命周期验证。

GitHub 仓库信息

信息	内容
项目标题	DPanel
项目描述	轻量化 Docker 与 Podman 可视化管理面板，用网页完成容器、镜像、Compose、网络和存储管理。
GitHub 仓库	donknap/dpanel
官网地址	https://dpanel.cc
主要开发语言	Go 96.83%、Makefile 1.42%、HTML 0.76%
开源许可证	自定义许可证：社区版仅限非商业用途；商业使用需另行授权
最近代码更新	2026-09-08（GitHub pushed_at，核对日期：2026-09-11）

面板解决的三件事

看清容器的当前状态

DPanel 将容器列表、详情、资源状态、日志和启停操作放到同一套界面。对一台同时运行下载器、数据库和个人站点的服务器来说，读者不必先记住容器 ID，再组合 docker inspect、docker logs 和 docker restart。固定版本源码中的容器控制器最终仍调用 Docker API，所以面板展示的是 Docker Engine 的实际对象，不是一份脱离运行环境的项目清单。

源码还把“频繁重启”纳入运行状态判断：运行状态逻辑会统计没有镜像健康检查的容器在最近一分钟内的启动与重启次数，达到三次便标成异常。这比只看 running 多了一层线索，但不能替代业务探针。网页返回 200、容器处于运行态，也不等于数据库连接或定时任务已经正常。

把散落的 Compose 文件纳入管理

DPanel 可以从 YAML 文本、远程 YAML 地址、Git 仓库或挂载到 /dpanel/compose 的目录创建 Compose 项目。后者尤其适合已有文件的自托管服务器：每个项目保留自己的子目录，DPanel 自动发现其中的 compose.yaml、compose.yml 或兼容文件。

相对目录需要特别留意。若项目文件位于 /dpanel/compose/blog/compose.yaml，其中的 ./data:/data 会对应到 DPanel 数据目录下的 compose/blog/data。使用宿主机目录挂载整个 /dpanel 时，这个映射关系直观且便于备份；只使用 Docker 命名卷时，卷内路径不能直接当作普通宿主机路径。官方文档给出了 volume.subpath 方案，但要求 Docker API 1.45 及以上，并且子目录要预先存在。

把变更操作留在可观察的流程里

创建、升级和删除都不是单纯改一行配置。DPanel 会将表单参数转换成 Docker 的容器配置、主机配置和网络配置，随后创建并按需启动容器；日志读取则直接接到 Docker 日志流。删除时，是否连同存储卷和镜像一起删除是独立选择。

可视化界面减少了命令拼写成本，却不会降低操作本身的破坏力。勾选“删除卷”仍会删除业务数据，错误的宿主机挂载仍可能暴露敏感目录。面板适合让动作更容易看懂和复核，不能代替权限设计与备份。

采用前先做判断

DPanel 比较适合以下环境：已有一台或少量 Docker 主机，希望用中文界面处理容器日常运维；Compose 文件需要统一归档；使用者理解镜像、端口和卷，只是不想每次都从命令行重新拼参数。

以下情况应换一种路径：

• 团队需要 Kubernetes 编排、声明式发布、审计审批或多租户隔离时，应采用对应的集群管理与 GitOps 工具。
• 只管理 Compose 文件、希望工具职责更窄时，可以比较 Dockge；更成熟的多环境容器管理需求可以比较 Portainer；一台机器上只有两三个稳定容器时，Docker CLI 与受版本控制的 Compose 文件往往已经够用。
• 公司、经营性网站或其他商业场景不能直接按普通开源软件采用。DPanel 的自定义许可证只允许非商业用途，商业使用需要获得授权，派生版本再分发也有限制。

Community Edition 分为标准版和 Lite 版。标准版内置 Nginx、域名转发与证书相关能力，会使用 80、443 和 8080；Lite 版只提供容器管理面板，镜像仅声明 8080。已有反向代理或只想先管理容器时，Lite 版减少了端口冲突，也让入口职责更清楚，因此下面选择 Lite。

用 Compose 部署 Lite 版

版本与前提

项目	本文选择
项目版本	DPanel 1.10.8 Community Edition Lite
部署日期	2026-09-11
镜像	阿里云官方镜像 registry.cn-hangzhou.aliyuncs.com/dpanel/dpanel:1.10.8-lite
镜像平台	linux/amd64、linux/arm64、linux/arm/v7
面板入口	127.0.0.1:8807，默认不对局域网或公网开放
持久化	宿主机 /opt/dpanel/data 映射到 /dpanel
验证等级	image-checked：已核对镜像索引、amd64 配置与 Compose 语法；未启动容器

机器需要安装 Docker Engine 与 Docker Compose v2，并允许当前管理员使用 sudo。端口 8807 需保持空闲。官方文档没有给出最低 CPU 和内存数值，因此部署前应先查看 Docker 主机的可用资源和现有容器负载：

sudo docker info --format 'CPUs={{.NCPU}} Memory={{.MemTotal}}'
sudo docker stats --no-stream
df -h /opt

这些结果用于确认主机仍有 CPU、内存和磁盘余量，不能换算成未经官方确认的最低配置。/dpanel 会保存 SQLite 数据库、日志、Compose 文件、备份和证书，实际空间取决于快照与备份数量。业务容器的数据卷不一定在这个目录中，需要另行纳入备份。

镜像同时固定 tag 与多架构索引摘要，避免同名 tag 后续指向不同内容。本文成功核对了阿里云官方镜像；Docker Hub 元数据查询在本次检查中超时，因此部署示例不使用未完成核验的 Hub 地址。

创建配置

在宿主机创建专用目录，然后进入该目录：

sudo install -d -m 0750 /opt/dpanel/data
cd /opt/dpanel

将下面内容保存为 /opt/dpanel/compose.yaml：

services:
  dpanel:
    image: registry.cn-hangzhou.aliyuncs.com/dpanel/dpanel:1.10.8-lite@sha256:c6e9faab74fce9ae7394098cf696e2a5689415eb29f69c7be23bdac175dc7114
    container_name: dpanel
    restart: unless-stopped
    ports:
      - "127.0.0.1:8807:8080"
    environment:
      APP_NAME: dpanel
      TZ: Asia/Shanghai
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - /opt/dpanel/data:/dpanel
    extra_hosts:
      - "host.dpanel.local:host-gateway"
    logging:
      driver: json-file
      options:
        max-size: "5m"
        max-file: "10"

APP_NAME 必须与 container_name 一致，面板依赖这个名称识别自身容器。host.dpanel.local 让 DPanel 管理的容器可以通过约定名称访问宿主机服务。日志轮转只限制 DPanel 容器的 Docker 日志，不会自动清理 /dpanel 内的应用日志或备份。

先让 Compose 解析配置，再拉取并启动：

cd /opt/dpanel
sudo docker compose config --quiet
sudo docker compose pull
sudo docker compose up -d

第一条命令没有输出并返回 0，表示 Compose 结构可解析；这项静态检查不会验证镜像能启动。启动后检查容器与日志：

sudo docker compose ps
sudo docker compose logs --tail=100 dpanel
curl -I http://127.0.0.1:8807/

预期 docker compose ps 显示 dpanel 为 running，日志没有持续重启，HTTP 请求能收到响应。若本机使用 SSH 管理服务器，可以从自己的电脑建立隧道：

ssh -L 8807:127.0.0.1:8807 your-user@your-server

随后在本机浏览器打开 http://127.0.0.1:8807。首次页面会要求创建创始账号；固定版本源码限制创始账号只能创建一次。请使用独立的高强度密码，不要复用服务器或镜像仓库凭据。

完成一次有效体验

进入面板后，不要把“页面打开”当成最终验收。用一个无凭据、无持久化数据的容器走完核心操作：

1. 在容器创建页面填写容器名 dpanel-smoke，镜像使用 nginx:1.27.5-alpine。
2. 将宿主机 127.0.0.1:8088 映射到容器 80/tcp，重启策略保持关闭，不添加目录或存储卷。
3. 创建并启动后，在宿主机执行 curl http://127.0.0.1:8088/。成功信号是返回 Nginx 默认页面内容，并且 DPanel 的容器详情显示运行中。
4. 回到 DPanel 查看日志，然后停止、重新启动 dpanel-smoke，再次执行 curl。这一步同时验证日志、状态控制和端口映射。
5. 删除测试容器时不要选择删除镜像；本例没有数据卷。最后执行 curl http://127.0.0.1:8088/ 应连接失败，容器列表中也不再出现 dpanel-smoke。

这组容器生命周期操作比只看首页更有价值：成功结果可以确认浏览器中的动作确实抵达当前 Docker Engine，也让使用者在无业务数据的情况下熟悉删除边界。本文没有实际执行这组运行时验收，以上是基于官方能力与固定版本源码整理的操作路径。

一次操作如何抵达 Docker

浏览器不会直接连接 Docker Socket。DPanel 的 HTTP 控制器先校验请求与登录状态，再调用业务逻辑和 Docker SDK；Docker Engine 执行创建、启停、日志或删除动作。DPanel 自己的配置与操作记录进入 /dpanel，业务容器的数据仍由各自的卷或宿主机目录负责。

Mermaid 流程图

正在准备渲染...

查看源码

flowchart LR
    B[浏览器中的 DPanel] -->|登录与管理请求| H[HTTP 控制器]
    H --> L[容器与 Compose 逻辑]
    L --> S[Docker SDK]
    S -->|Docker Socket| E[宿主机 Docker Engine]
    E --> C[业务容器、镜像、网络与卷]
    H --> D["/dpanel：SQLite、配置、日志、Compose、备份"]
    C --> V[业务数据卷或宿主机目录]

启动过程也解释了为什么 /dpanel 必须整体持久化：主程序会同步数据库结构、执行版本迁移、创建 backup、compose、logs、cert 等子目录并生成登录令牌使用的 RSA 密钥。只备份 dpanel.db 会漏掉 Compose 文件、证书和备份；只备份 Compose 文件又会丢失面板配置与账号。

日常维护

查看日志与验证持久化

遇到页面无法打开时，先看容器状态和最近日志：

cd /opt/dpanel
sudo docker compose ps
sudo docker compose logs --tail=200 dpanel
sudo ls -lah /opt/dpanel/data/dpanel.db /opt/dpanel/data/logs/

完成首次账号设置后，可执行一次普通重建：

sudo docker compose up -d --force-recreate

刷新页面后仍能使用原账号登录，/opt/dpanel/data/dpanel.db 仍存在，才说明 DPanel 自身数据跨容器重建保留。这个检查不覆盖业务容器的卷。

冷备份与恢复

SQLite 数据库在运行中可能写入。最容易解释的一致性方案是短暂停止 DPanel，再打包整个数据目录。以下命令从 /opt/dpanel 执行：

cd /opt/dpanel
sudo docker compose stop dpanel
sudo tar -C /opt/dpanel -czf "dpanel-backup-$(date +%Y%m%d-%H%M%S).tar.gz" data

确认 tar 返回 0 后再启动面板；若归档失败，应先记录错误并明确这次备份无效，然后再决定修复问题或恢复服务。启动后检查归档能被读取，并把备份复制到另一块磁盘或远端备份系统：

sudo docker compose start dpanel
sudo tar -tzf /opt/dpanel/dpanel-backup-YYYYMMDD-HHMMSS.tar.gz | head

恢复会覆盖当前面板状态。先停止服务，把现有目录改名保留，再解压指定归档：

cd /opt/dpanel
sudo docker compose stop dpanel
sudo mv data "data.before-restore-$(date +%Y%m%d-%H%M%S)"
sudo tar -xzf dpanel-backup-YYYYMMDD-HHMMSS.tar.gz
sudo docker compose start dpanel
sudo docker compose logs --tail=100 dpanel

登录并核对容器连接、Compose 项目和设置后，再决定是否删除 data.before-restore-*。DPanel 的容器快照也写在 /dpanel/backup，但容器快照面向被管理容器；宿主机上其他目录和命名卷仍要单独备份。

升级与回滚

升级前先阅读目标版本的 Release 与文档变更，完成冷备份，并记录当前镜像行。不要直接把 1.10.8-lite 换成 latest。将 compose.yaml 中的 tag 和摘要一起替换为已经核对的平台索引，然后执行：

cd /opt/dpanel
sudo docker compose config --quiet
sudo docker compose pull
sudo docker compose up -d
sudo docker compose logs --tail=100 dpanel

官方面板内升级与手动安装程序都会重建 DPanel 容器；Compose 管理的实例更适合继续在 Compose 文件中固定版本。升级失败时，先恢复旧镜像行并重建；若新版本已经迁移数据且旧版本无法读取，再按上一节恢复升级前的完整 /dpanel 冷备份。本文没有执行升级、数据迁移回滚或跨版本恢复，因此生产使用前应在副本上演练。

停用与卸载

临时停用只需停止 DPanel，现有业务容器仍由 Docker Engine 继续运行：

cd /opt/dpanel
sudo docker compose stop dpanel

确定不再使用面板时，先完成并验证冷备份，再移除 DPanel 容器和本 Compose 创建的网络：

cd /opt/dpanel
sudo docker compose down

docker compose down 不会删除绑定目录 /opt/dpanel/data，也不会自动删除 DPanel 管理过的业务容器、业务镜像或业务卷。确认备份可恢复且数据不再需要后，才能单独处理 /opt/dpanel/data；保留该目录可以为重新部署或人工取回 Compose 文件留下余地。

常见卡点

页面打不开

先运行 sudo docker compose ps。容器反复重启时查看 sudo docker compose logs dpanel；容器正常但远端浏览器打不开，多半是因为本文只绑定了 127.0.0.1。优先使用 SSH 隧道。确需局域网访问时，可把端口改为 LAN_IP:8807:8080，并在主机防火墙中只允许可信网段；不要直接改成不受限制的公网监听。

面板看不到 Docker 容器

检查 Socket 是否存在以及 DPanel 的挂载：

sudo test -S /var/run/docker.sock
sudo docker inspect dpanel --format '{{json .Mounts}}'
sudo docker compose logs --tail=100 dpanel

macOS 的 Docker Desktop Socket 位置可能不同，官方 README 给出了用户目录下 Socket 的挂载方式。不要为了绕过权限错误把整个宿主机目录无选择地挂进容器。

APP_NAME 或容器名不一致

症状通常出现在面板识别自身、更新或实例信息上。确保 container_name: dpanel 与 APP_NAME: dpanel 完全一致，随后执行 sudo docker compose up -d --force-recreate 并重新查看日志。

Compose 相对挂载不符合预期

先确定 YAML 在 /dpanel/compose 中的实际目录，再把相对路径换算到宿主机 /opt/dpanel/data/compose。若 /dpanel 使用 Docker 命名卷，普通 ./data:/data 不能自动变成卷内子目录；可改用明确的宿主机目录，或在满足 Docker API 版本要求时按官方文档配置 volume.subpath。

安全与使用边界

Docker Socket 是整套部署中最重要的风险点。即使写成 :ro，Socket 客户端仍可向 Docker 守护进程发送创建容器等管理请求；文件系统的只读标记不会把 Docker API 变成只读。应限制谁能登录 DPanel、谁能访问面板入口，并将 DPanel 与普通公开网站分开部署。

另外需要处理四个具体问题：

• 只在本机或管理网络开放 8807；需要 HTTPS 时放在受控反向代理后，并保留来源地址限制。
• 为镜像升级记录 tag 与摘要，先在副本验证。摘要固定了内容，但不会自动证明镜像可信或没有漏洞。
• 定期备份 /dpanel 与业务容器数据，分别验证恢复。面板备份目录与真正的离机备份不是一回事。
• 非商业许可会直接影响公司和经营性用途。采用前应由实际使用方核对许可证并取得所需授权。

完成最小体验后，下一步可以把一个已有 Compose 项目复制到 /opt/dpanel/data/compose/<项目名>/，观察 DPanel 如何发现该项目；在真正部署前，先确认所有相对挂载都落到预期宿主机目录。这次试迁移能检验 DPanel 是否适合接管现有文件组织，而不会立刻迁移全部服务。

参考资料

• DPanel GitHub 仓库
• DPanel v1.10.8 Release
• Docker Compose 安装
• 配置参数
• 使用 Compose 创建容器
• Compose 相对目录
• 更新 DPanel 面板
• 容器快照
• 社区版许可证