Day: February 7, 2026

背景 在多 Compose 栈并存的环境里，迁移完成后常见现象是： 目标是：先盘点，再确认引用关系，最后最小化删除，避免误删关键数据。 核心原则 1) 先确认“新数据落点”是否稳定 迁移成功的强信号通常是：关键服务容器的持久化目录全部使用 bind mount，且映射到统一的宿主机工作目录结构。 2) named volume 的风险等级更高 在多栈环境里，named volume 很可能承载关键数据，例如： 结论：只有当卷确认“零引用”且业务已稳定使用 bind mount 时，才进入删除阶段。 盘点步骤 Step A：列出所有卷（建立资产清单） 只列出“无引用候选”（只做名单，不删除）： Step B：列出所有容器（包含已停止） 目的： Step C：从容器侧确认挂载类型（关键确认） 对“目标业务容器”查看挂载： 关注点： 若目标业务容器已完全为 bind mount，说明迁移落点基本完成。 识别“迁移搬运容器” 迁移时常用方式是： 这类容器特征： 验证方式：列出某个卷当前被哪些容器引用（最重要的安全检查）： 安全清理顺序 ① 先删“迁移搬运容器” 前提：确认这些容器不再需要、并且目标业务已稳定运行。 ② 再做“卷引用归零”验证 对每个旧卷执行： 判定规则： ③ 最后删除确认无引用的旧卷 …

背景 在使用 onlyoffice/documentserver 单容器部署 OnlyOffice 的过程中，虽然已经将常见目录（logs / data / cache / public / fonts）通过 bind mount 挂载到了用户目录，但在实际检查容器挂载点时，仍然发现 /var/lib/docker/volumes/ 下存在多组随机字符串命名的 volume。 这类 volume 并非人为创建，而是镜像在 Dockerfile 中通过 VOLUME 指令声明后，由 Docker 自动生成的匿名卷。如果不显式覆盖挂载，这些卷会默默承载真实数据，从而破坏“栈内统一、目录可迁移”的目标。 本文记录一次完整的排查与修正过程，将 OnlyOffice 的 全部持久化数据 统一收敛到单一项目目录下，并清理匿名卷依赖。 问题确认：匿名卷从何而来 通过以下命令检查容器挂载点： 可以观察到： 这些匿名卷对应的典型路径包括： 结论：OnlyOffice 内部依赖的 PostgreSQL / RabbitMQ / Redis 等组件，其数据仍然落在 Docker 管理区，而非项目目录。 目标 现有目录结构（示例） …

一、问题背景（抽象化） 在一台长期运行的 Linux 主机上，使用 Docker Compose 部署了多个应用栈。随着时间推移，出现了以下典型问题： 目标不是改变 Docker 的存储机制，而是： 在不破坏 Docker 设计的前提下，让数据卷“可读、可控、可迁移”。 二、总体设计原则（通用） 1. 不强行迁移 Docker 根目录 2. 明确区分三类数据 类型 处理方式 Compose / 配置文件 保留在用户可读目录 运行期业务数据 使用 命名 volume 临时 / 缓存数据 允许 Docker 自动管理 3. 通过“命名 volume”解决可读性问题 三、问题定位方法（通用步骤） 1. 列出系统中所有 volume 2. 反向确认 volume 与容器的挂载关系 通过该方式，可以明确： 四、数据迁移的通用流程 步骤 …

背景 在单机环境中使用 Docker Compose 同时运行 Ollama（推理核心）与 Open-WebUI（交互界面）是一个常见做法。初期将两者放在同一个 compose 文件中管理较为方便，但随着系统逐步演进，这种方式会带来以下问题： 因此，本次实践的目标是： 在不丢失任何既有数据的前提下，将 Ollama 与 Open-WebUI 拆分为两个独立的 Docker Compose 栈，并通过一个核心网络进行连接。 设计原则 原始状态分析 在最初的一体化部署中，Docker 会自动为服务创建数据卷。拆分为多个栈后，如果未显式指定旧数据卷名称，Docker 会为新栈创建新的空卷，从而导致“历史数据消失”的错觉。 需要明确的是： 数据通常并未被删除，而是新容器未挂载到正确的旧数据卷。 因此，拆分过程中最关键的工作并不是服务启动顺序，而是数据卷的精确绑定。 拆分思路概述 整体架构被拆分为两类栈： 所有服务间通信均通过 Docker 内部网络完成，核心服务不直接对外暴露。 核心栈配置要点（示意） 核心栈的职责包括： 配置示意（省略非关键字段）： 外围栈配置要点（示意） 外围栈的职责包括： 配置示意（省略非关键字段）： 常见问题与判断方法 为什么拆分后看起来“数据没了”？ 如何判断旧数据卷是否仍然存在？ 可通过 Docker 的卷列表与磁盘占用信息进行判断。通常： 最终状态 在完成拆分与修正后，系统应达到以下状态： 总结 本次实践的核心经验可以归纳为一句话： Docker 不会替用户判断应当使用哪个历史数据卷，所有关键数据都必须显式绑定。 通过明确： …

背景 在长期运行的 Docker 环境中，随着容器的反复创建、删除与重建，系统中可能残留未被任何容器使用的卷（volume）。这些卷如果不加区分地清理，存在误删有效数据的风险；如果完全不清理，又会造成系统状态不透明。 本文记录一次严格、可验证的 Docker 卷清理过程，目标是： 一、初步筛选：dangling volume Docker 提供了对“悬空卷（dangling volume）”的定义： 未被任何容器引用的卷 使用以下命令列出： 输出结果为两个卷 ID： 该步骤只能说明： 这些卷当前没有被容器引用 但仍需要进一步验证它们的空间占用与引用状态。 二、空间与引用状态交叉验证 通过 docker system df -v 查看本地卷的使用情况，并重点关注两项信息： 关键结果如下（节选）： 可以确认： 三、判断结论 综合两次验证结果： 卷 ID LINKS SIZE 状态 14ab1c74859f… 0 7.7 kB 未被使用 ebd2fa33478… 0 90 kB 未被使用 结论： 四、安全删除方式 明确目标卷后，采用精确删除而非批量清理： 该方式的优点是： 五、实践原则总结 …