开发者工作流：把 NAS 变成私人基础设施

目标：代码有地方放、依赖服务随时可用、在外面也能连回来调试，而且换电脑时不用重建一切。

前置条件

• Docker 入门已读完，目录规划已定。
• 已读SSH 与命令行，了解在 fnOS 上直接改系统的边界。

步骤

1. 先定目录结构

所有服务的配置和数据统一放在一处，见规划 Docker 应用目录与权限。一个够用的划分：

/vol1/docker/
  stacks/        # 所有 compose 文件（这是最该备份的目录）
  data/<应用>/   # 各应用的数据
/vol1/projects/  # 代码仓库和工作目录

2. 自建 Git 仓库

部署 Gitea，把私有项目放进去。

同时把 stacks/ 目录也做成一个仓库：每次改 compose 都提交。改坏了能看到改了什么并回滚，换机器时克隆下来就能重建全部服务。注意用 .env 存放敏感信息，并在 .gitignore 里排除它。

3. 部署依赖服务

开发常用的数据库和缓存跑在 NAS 上，本地机器就不用装一堆东西：

• PostgreSQL：注意固定主版本号，跨版本升级需要迁移数据。
• Redis 之类的缓存服务同理。

不要把数据库端口映射到宿主机

同一个 compose 网络里的容器用服务名互访即可。确实需要从本地电脑连接时，通过私有网络组网，而不是把端口暴露出去——数据库端口是自动化扫描的重点目标。

4. 配好远程访问

在外面要连回来时，Tailscale 一类的组网方案是最省事的：装上客户端，NAS 就像在同一个局域网里，SSH、数据库、网页服务全都能直接访问，公网上不需要开任何端口。

5. 把重复操作自动化

需要定时任务、Webhook 触发、跨服务联动时，用 n8n。但要诚实评估：只有一两个定时任务的话，系统自带的计划任务加一个脚本更简单，也少一个需要维护的服务。

6. 加上监控

服务多起来之后，挂了要能知道。部署 Uptime Kuma，把每个服务的地址加进去，见监控与告警。

7. 备份策略要分类

数据	策略
Git 仓库	严格备份（每个克隆也是一份副本，但 issue 和配置不是）
数据库	用 pg_dump 等工具导出，不能直接复制数据目录
compose 文件	严格备份，重建服务时它能省掉几天
容器镜像	不备份，重新拉取即可
构建缓存	不备份

详见备份体系。

验证

模拟一次「换电脑」：

1. 在另一台机器上克隆 stacks 仓库。
2. 按照 compose 文件在测试目录里重建一个服务。
3. 从备份恢复它的数据。
4. 确认服务正常工作。

能走完这一遍，说明你的基础设施是可重建的——这比任何文档都能说明问题。

容易出问题的地方

问题	原因
密钥被提交进了仓库	没有用 .env 加 .gitignore
数据库升级后起不来	用了 latest 标签，跨主版本自动跳了
恢复时发现备份是坏的	直接复制了运行中的数据库文件
硬盘一直不休眠	数据库和构建缓存在机械盘上，见功耗

延伸阅读

• Docker 入门
• SSH 与命令行
• 网络进阶