读书笔记 · 约 14,064 字 · 预计推送 2 部分

Docker Compose 个人服务部署：镜像、卷、网络、更新、备份与安全（Windows 适配）精读 未开始

目录

题记与说明

来源清单

#来源性质获取方式
1Install Docker Desktop on Windows — Docker Docs官方文档（全文）webReader 全文
2Best practices (WSL 2) — Docker Docs官方文档（全文）webReader 全文
3Volumes — Docker Docs官方文档（全文）webReader 全文
4Use Compose in production — Docker Docs官方文档（全文）webReader 全文
5Use Compose Watch — Docker Docs官方文档（全文）webReader 全文
6Backup and restore data — Docker Docs官方文档（要点+引述）WebFetch 提取
7Accessing network applications with WSL — Microsoft Learn官方文档（全文）webReader 全文
8Improve disk performance — VS Code Docs微软官方文档（要点+引述）WebFetch 提取
9containrrr/watchtower — GitHub README一手项目页（要点+引述）WebFetch 提取
10Docker Security Cheat Sheet — OWASP行业标准清单（要点+引述）WebFetch 提取
附Anicholas-fedor/watchtower（Watchtower 继任 fork）仅搜索级核验，未深读WebSearch
附Br/docker、Docker Forums、Medium 上关于 WSL2 bind mount 慢 10–60 倍的社区说法仅搜索级，未采信为数据WebSearch

七维提取

1. 核心问题

个人开发者在一台 Windows 常开机器上用 Docker Compose 自托管服务（n8n、数据库、网盘、面板等），本质要同时回答六个子问题：

  1. 镜像：用哪个 tag、谁负责更新、更新到什么粒度；
  2. 卷：数据放 named volume 还是 bind mount——这一选择在 Windows 上因"容器跑在 WSL2 VM 里"而与 Linux 完全不同；
  3. 网络：服务如何暴露给本机/局域网，WSL2 的 NAT 架构和 Windows 防火墙加了哪些额外环节；
  4. 更新：手动、半自动还是全自动，自动化工具本身的维护状态是否可靠；
  5. 备份：镜像、卷、配置各自怎么备份，Windows 侧多出来的 VHDX 磁盘怎么处理；
  6. 安全：个人部署最常见的取舍——便利性换掉了哪些默认防线，以及 Docker Desktop 在 Windows 上的特权模型。

贯穿性问题：Windows 上 Docker 的"VM 边界"如何改变这六个子问题的最优解。

2. 主要主张

M1 卷是持久化的首选机制，Windows 上更是如此。 官方原话："Volumes are the preferred mechanism for persisting data generated and used by Docker containers"，理由包括 "Volumes are easier to back up or migrate than bind mounts"、"Volumes work on both Linux and Windows containers"、"When your application requires high-performance I/O"（来源3）。bind mount 只在"需要从宿主机和容器两侧访问文件"时使用："Use bind mounts if you need to access files or directories from both containers and the host"（来源3）。

M2 Windows 上 bind mount 一律避免指向 /mnt/c/...（即 Windows 文件系统）。 Docker 官方 WSL 最佳实践："Performance is much higher when files are bind-mounted from the Linux filesystem, rather than remoted from the Windows host. Therefore avoid docker run -v /mnt/c/users:/users"（来源2）。且 inotify 会失效："Linux containers only receive file change events, 'inotify events', if the original files are stored in the Linux filesystem"（来源2）。根源是 VM："macOS and Windows run containers in a VM, 'bind' mounts are not as fast as using the container's filesystem directly"（来源8）。社区口径量化为 10–60 倍差距（附B，非官方数据，未实测）。

M3 长期运行的 compose 部署应有独立的 production 覆盖文件与显式重启策略。 官方建议改动包括 "Removing any volume bindings for application code, so that code stays inside the container and can't be changed from outside" 与 "Specifying a restart policy like restart: always to avoid downtime"，用 docker compose -f compose.yaml -f compose.production.yaml up -d 叠加生效；单服务重新部署用 docker compose build web && docker compose up --no-deps -d web（来源4）。

M4 全自动更新工具 Watchtower 已死，不能作为个人基础设施的长期依赖。 仓库已被归档："This repository was archived by the owner on Dec 17, 2025. It is now read-only"、"⚠️ This project is no longer maintained"，官方明确 "We do not recommend using Watchtower in a commercial or production environment"（来源9）。社区公认的继任 fork 是 nicholas-fedor/watchtower，镜像 nicholasfedor/watchtower / ghcr.io/nicholas-fedor/watchtower，已修复 Docker Engine 29 兼容性（附A，仅搜索级核验）。

M5 备份必须分三层，且卷数据不在镜像里。 官方明确："filesystem changes in a volume that are attached to the container are not included in the image, and must be backed up separately"（来源6）。三层 = ①卷数据（tar 或数据库原生 dump）；②镜像（docker container commit + docker image save -o images.tar 或 docker push）；③灾难级——Docker Desktop 全停后备份 VM 磁盘文件，WSL2 后端为 %LOCALAPPDATA%\Docker\wsl\disk\docker_data.vhdx，且前提是 "Docker Desktop must be fully stopped before backing up these files"（来源6）。

M6 安全基线是一套固定的 compose 级配置组合，而非某个单一开关。 OWASP 清单的可落地子集：不挂载 docker.sock（"Giving someone access to it is equivalent to giving unrestricted root access to your host"，RULE #1）、非 root 运行（"Configuring the container to use an unprivileged user is the best way to prevent privilege escalation attacks"，RULE #2）、cap_drop: [ALL] 后按需添加（RULE #3）、security_opt: [no-new-privileges:true]（RULE #4）、端口只绑 127.0.0.1（RULE #5，Docker 会绕过 UFW）、资源限制（RULE #7）、read_only + tmpfs + :ro（RULE #8）、Trivy/Grype 扫镜像（RULE #9）（来源10）。

M7 Windows 网络默认 NAT，Win11 22H2+ 建议切 mirrored 模式。 微软官方："By default WSL uses a NAT based architecture, and we recommend trying the new Mirrored networking mode"；mirrored 模式收益包括 IPv6、双向 localhost、VPN 兼容、组播、LAN 直连（来源7）。要让局域网访问容器，还需 Hyper-V 防火墙放行：Set-NetFirewallHyperVVMSetting -Name '{40E0AC32-46A5-438A-A0B2-2B479E8F2E90}' -DefaultInboundAction Allow（来源7）。

M8 Docker Desktop 在 Windows 上的特权模型有明确的安全提示。 per-user 安装模式 "Smaller attack surface; no privileged system service installed"，不需要管理员权限安装/更新（来源1）；而 docker-users 组 "grants access to the Docker daemon socket, which is equivalent to granting administrative privileges on the host"（来源1）。

3. 方法

本次研究方法：官方文档优先的三角化检索。Docker 官方（Desktop 安装、WSL 最佳实践、Engine 卷、Compose 生产/Watch、Desktop 备份）负责"怎么做"；Microsoft Learn 负责 WSL 网络架构这一 Windows 侧独有环节；OWASP 负责安全基线；GitHub 一手页面核验自动化工具的存活状态。对社区流传的性能数字（10–60 倍）只收录为"社区口径"并标注未实测，避免把论坛数据当证据。

领域本身的技术路线（文档给出的标准做法）：

4. 数据与证据

卷选型与备份（来源3，全文）

Windows 文件性能（来源2 全文 + 来源8 提取）

Windows 安装与系统要求（来源1，全文）

网络（来源7，全文）

更新（来源9、5）

备份（来源6）

安全（来源10）

5. 结论

一套在 Windows 上可长期运行的 Compose 个人服务架构基线（全部条目可追溯到上述来源）：

  1. 安装层：per-user 模式 + WSL2 后端（个人使用免费、攻击面最小、免管理员）；Win11 22H2+ 把 .wslconfig 改 networkingMode=mirrored；Docker Desktop 设开机自启，容器配 restart: unless-stopped。
  2. 数据层：一切有状态服务用 named volume；bind mount 只用于少数配置文件，且绝不挂 /mnt/c 下的路径；改配置→重启容器，而不是挂载宿主目录热改。
  3. 网络层：ports: ["127.0.0.1:8080:80"] 默认只绑本机；需要局域网访问的服务单独放开并配 Hyper-V 防火墙规则；network_mode: host 不用（在 Desktop 上无 Linux 语义——基于已有知识，本次来源未覆盖）。
  4. 更新层：不依赖 Watchtower（已归档）；用受控流程 docker compose pull && docker compose up -d，月度执行；若要自动化，迁移到社区 fork nicholasfedor/watchtower 并接受"它握有宿主 root"这一前提。
  5. 备份层：卷数据用数据库原生 dump（Postgres pg_dump / MySQL mysqldump）或 tar（来源3 流程）；配置与 compose 文件进 git（.env 除外）；每季度全停 Desktop 冷备 docker_data.vhdx；三副本两介质一异地（与既有备份笔记的 3-2-1 原则衔接）。
  6. 安全层：compose 里统一加 user、cap_drop: [ALL] + 按需 cap_add、security_opt: ["no-new-privileges:true"]、read_only: true + tmpfs、资源限制；不挂 docker.sock 给任何服务；镜像用 Trivy 扫描；保持 Docker Desktop 与 WSL 更新（OWASP RULE #0）。

6. 局限

来源自身承认的局限：

本次研究的局限：

7. 对我的启发

  1. 本机环境直接适用：这台机器就是 Windows + Git Bash 环境。若在 D: 盘跑个人服务，切勿把数据库/有状态服务的 ./data 目录 bind mount 进容器——把 named volume 作为默认，数据在 VHDX 里由 Docker 管理，备份走 dump 而非拷目录。
  2. 与既有备份体系打通：卷 dump 产物是普通文件，正好接入已有的 3-2-1 备份流（2026-10-31-knowledge-fexxiou8-4 笔记）；VHDX 冷备是新增的"灾备层"，要排在备份计划的最低频档位。
  3. 与 n8n 自托管衔接：n8n 笔记里的自托管方案若用 compose，应补上本次的安全基线（127.0.0.1 绑定、no-new-privileges、资源限制）与更新流程（pull + up -d，而非 Watchtower）。
  4. 本地 LLM 服务：若把 ollama/推理服务容器化，GPU passthrough + WSL2 是 Windows 侧路径；但大模型权重属重 I/O 只读数据，放 named volume 或镜像层都比 /mnt/c bind mount 好。
  5. 写文档的启示：官方文档对"Windows 上为什么慢"只有定性说法，真正可引用的量化数字要自己跑基准——这是一个值得后续实测补数据的小课题（named volume vs /mnt/c bind mount vs WSL2 FS bind mount 的 IOPS/延迟对比）。
  6. 方法论：判断"某工具还能不能进个人技术栈"，维护状态（archived 与否）比功能列表更重要——Watchtower 功能完美但已死，这类信号要在选型时一票否决。

关键原文摘录索引

← 资料库今日播报 →