如前文所述,搭建这台 12500T 计算端的核心目的,就是为了彻底剥离群晖的计算任务,并分担我高频使用的部分核心功能。当我理清思路,发现仅仅依靠 Docker 就能完美覆盖我所有的需求时,我毫不犹豫地放弃了 PVE 的多层虚拟化嵌套,转而投入了 Debian 13 原生 Docker 的怀抱。
相比于生硬的部署教程,我更想聊聊“为什么搭”——在这个 32GB 内存的 Debian 系统上,每一个容器的存在都有其明确的现实意义。
1. 基础设施与网关服务:家庭数据中心的基石
NPM (Nginx Proxy Manager 流量网关) NPM 是整个计算端面向公网的核心网关,承担着端口收敛与安全加密的任务。如果没有反向代理,每一个对外暴露的服务都需要在软路由上单独设置端口转发,访问时必须在 IP 后手动添加端口号。这会向公网暴露过多的主机端口,增加被扫描的风险。 NPM 改变了这种粗放的流量分发逻辑。它配合 DuckDNS 动态解析,将外网的所有访问请求统一收口在标准 Web 端口(80 和 443)上。当外部访问到来时,NPM 会读取请求的域名头,根据预设规则,在主机内部将流量精准路由到对应 Docker 容器的具体端口。 虽然这种处理方式就是导致上述“超长三级域名”痛点的直接原因,但它带来的安全收益是绝对刚需的。NPM 内置了 Let’s Encrypt 接口,能够为这些冗长的域名全自动申请并定期续签 SSL 安全证书。它强制所有内外网交互走 HTTPS 加密协议,直接消除了浏览器访问自建服务时的证书报错警告,确保了数据在公网传输中的隐蔽性和安全性。
Compose 文件
version: '3.8'
services:
npm:
image: 'jc21/nginx-proxy-manager:latest'
container_name: npm
restart: unless-stopped
ports:
- '80:80' # HTTP 流量
- '443:443' # HTTPS 流量
- '81:81' # 管理界面端口
volumes:
- /docker/npm/data:/data
- /docker/npm/letsencrypt:/etc/letsencrypt
Homarr (系统监控与导航面板) Homarr 是我目前浏览器打开的默认主页,其核心价值在于解决服务入口激增带来的访问痛点。由于后续部署的容器数量多达十几个,在配合 DuckDNS 和反向代理之后,产生了一个非常现实的困扰:DuckDNS 本身提供的是二级域名,经过反代拆分,每一个内部服务都会生成一个极其冗长的三级甚至四级域名(例如 nextcloud.你的前缀.duckdns.org)。这种长链接在跨设备访问或手动输入时体验极差,依靠浏览器书签进行管理的效率也很低。 Homarr 通过可视化的磁贴矩阵,将所有 Web 端应用的入口统一整合在一个页面内,点击即可跳转,彻底免去了记忆和输入长 URL 的麻烦。除导航功能外,它具备极强的系统信息聚合能力。通过挂载系统的 Docker socket,我可以在首页直观地监控 12500T 核心线程的占用率、32GB 内存的实时分配情况,以及 28TB iSCSI 网络硬盘的剩余容量。将底层物理硬件状态与应用层入口集成在同一个前台面板中,大幅提升了日常维护的效率。
Compose 文件
services:
homarr:
container_name: homarr
image: ghcr.io/ajnart/homarr:latest
restart: unless-stopped
volumes:
- /docker/homarr/configs:/app/data/configs
- /docker/homarr/icons:/app/public/icons
ports:
- '7575:7575'
2. 研究中枢与生产力替代:把数据主权握在手里
Syncthing (高频工作流同步) Syncthing 专注于多设备之间特定工作目录的实时文件同步。在当前的设备生态中,Time Machine 负责执行全盘的周期性历史快照备份并存储于 NAS,而 Syncthing 则专项负责高频工作流中的即时同步需求,两者互不冲突。 日常研究中,我会使用 MacBook Pro 进行论文撰写和文献整理。Syncthing 部署后会以底层服务持续运行,监控指定工作文件夹的变更状态。一旦检测到文件保存动作,它会立即利用局域网进行 P2P (点对点) 传输,在极短时间内将变更后的数据块同步到 12500T 服务器的对应目录中。这种去中心化的同步机制不需要将数据上传至公有云进行中转,实现了本地多设备之间内网环境下的无缝文件流转,保证了跨设备办公的连贯性。
Compose 文件
version: "3"
services:
syncthing:
image: syncthing/syncthing:latest
container_name: syncthing
hostname: Japan-Main-Node # 给你的日本节点起个好听的名字
environment:
- PUID=1000
- PGID=1000
- TZ=Asia/Tokyo
volumes:
- /docker/syncthing/config:/var/syncthing/config # 配置在 SSD
- /data:/var/syncthing/Sync # 数据在大硬盘
ports:
- 8384:8384 # Web GUI 端口
- 22000:22000/tcp # 数据传输端口
- 22000:22000/udp # 数据传输端口
- 21027:21027/udp # 本地发现端口
restart: unless-stopped
Nextcloud (自建私有云盘) 将 Nextcloud 部署在 12500T 的计算节点上,是贯彻“存算分离”架构的核心步骤。群晖自带的 Synology Drive 在处理常规文件同步时表现尚可,但在面对多文化社会学研究中产生的大量文献、扫描件以及高频的全文检索需求时,其搭载的低功耗处理器会出现明显的性能瓶颈,导致响应迟缓甚至卡顿。 通过自建 Nextcloud,我将文件系统的索引建立、全文搜索和在线协作等高负载计算任务,全部转移到了性能强劲的桌面级 CPU 上运行。此时,DS720+ 仅负责提供底层 iSCSI 块存储支持,不再参与文件逻辑处理。Nextcloud 极高的并发上限配合本地 32GB 内存构建的缓存,确保了海量文献资料在分类和检索过程中的极速响应,构建了一个绝对自主且无性能焦虑的核心研究资料中枢。
Compose 文件
version: '3.8'
services:
nextcloud-db:
image: mariadb:10.11
container_name: nextcloud_db
restart: always
command: --transaction-isolation=READ-COMMITTED --binlog-format=ROW
volumes:
- /docker/nextcloud/db:/var/lib/mysql
environment:
- MYSQL_ROOT_PASSWORD=12345678 # root密码
- MYSQL_PASSWORD=23456789 # 数据库密码
- MYSQL_DATABASE=nextcloud
- MYSQL_USER=nextcloud
nextcloud-redis:
image: redis:alpine
container_name: nextcloud_redis
restart: always
nextcloud-app:
image: nextcloud:latest
container_name: nextcloud_app
restart: always
depends_on:
- nextcloud-db
- nextcloud-redis
ports:
- "38081:80"
volumes:
- /docker/nextcloud/app:/var/www/html
- /data/Nextcloud/data:/var/www/html/data # 核心数据放在大硬盘
- /docker/nextcloud/custom_fonts:/usr/share/fonts/truetype/custom:ro # 注入字体
environment:
- MYSQL_PASSWORD=23456789 # 数据库密码
- MYSQL_DATABASE=nextcloud
- MYSQL_USER=nextcloud
- MYSQL_HOST=nextcloud-db
- REDIS_HOST=nextcloud-redis
- PHP_UPLOAD_LIMIT=10G
- PHP_MEMORY_LIMIT=4G
devices:
- /dev/dri:/dev/dri # 启用 Intel 核显加速
# [新增] 独立的 Collabora Online (CODE) 服务器
nextcloud-collabora:
image: collabora/code:latest
container_name: nextcloud_collabora
restart: always
ports:
- "9980:9980"
environment:
# 替换为你的实际域名,点号需要转义
- aliasgroup1=
- domain=
- username=
- password=
# 开启硬件加速选项
- extra_params=--o:ssl.enable=false --o:ssl.termination=true
volumes:
- /etc/localtime:/etc/localtime:ro
- /docker/nextcloud/custom_fonts:/usr/share/fonts/truetype/custom:ro # 关键:将字体注入编辑引擎
devices:
- /dev/dri:/dev/dri # 利用 i5-12500T 核显加速文档渲染
depends_on:
- nextcloud-app
WordPress (博客本地镜像站) 在本地部署 WordPress 容器,主要是为了建立一个零延迟的本地镜像创作环境。目前我面向公众的博客主站运行在腾讯云上,以确保国内网络的连通性。然而,从日本跨国连接云服务器进行后台维护和文章撰写时,不可避免地会产生网络延迟,这对高频的文字录入和排版工作会造成干扰。 本地镜像站通过千兆局域网直接提供服务,彻底消除了敲击键盘与后台响应之间的延迟差异。我现在所有的图文上传、草稿编辑和排版调整都在本地节点完成,操作体验与本地原生软件无异。完成定稿后,再将内容同步至云端主站。这种双节点模式既保证了极致的本地创作流畅度,也自然形成了一套完整的本地物理灾备方案,保障了所有文章数据的安全性。
Compose 文件
version: '3.1'
services:
wordpress:
image: wordpress:latest
container_name: wordpress-app
restart: always
ports:
- 8888:80
environment:
WORDPRESS_DB_HOST: db
WORDPRESS_DB_USER: wordpress
WORDPRESS_DB_PASSWORD: 12345678 #数据库密码
WORDPRESS_DB_NAME: wordpress
volumes:
- /docker/wordpress/html:/var/www/html
# 新增下面这一行,挂载自定义 PHP 配置
- /docker/wordpress/uploads.ini:/usr/local/etc/php/conf.d/uploads.ini
db:
image: mariadb:10.6
container_name: wordpress-db
restart: always
environment:
MYSQL_DATABASE: wordpress
MYSQL_USER: wordpress
MYSQL_PASSWORD: 12345678 #数据库密码
MYSQL_RANDOM_ROOT_PASSWORD: '1'
volumes:
- /docker/wordpress/mariadb:/var/lib/mysql
Trilium (知识树与思维图谱) Trilium 是一个具备强关系图谱生成能力的开源知识管理系统,我将其作为思维导图类收费软件(如 MindNode 和 Xmind)的替代方案。在进行社科和历史文献的交叉对比研究时,往往需要处理大量多维度的概念关联。传统的思维导图主要基于树状结构的单向发散,在处理复杂的网状逻辑时存在局限。 Trilium 支持在任意笔记节点之间建立双向链接,并能够根据这些链接自动渲染出可视化的全局关系图谱。这极大地提升了长线研究的逻辑梳理效率。此外,采用私有化部署,意味着所有思考数据均以标准开源格式存储在 12500T 挂载的底层数据库中。这确保了知识资产的完全自主可控,彻底规避了商业软件的数据格式锁定和持续订阅成本。
Compose 文件
services:
trilium:
image: zadam/trilium:latest
container_name: trilium
restart: always
ports:
- "8086:8080"
volumes:
- /docker/trilium:/home/node/trilium-data
environment:
- TRILIUM_DATA_DIR=/home/node/trilium-data
3. 影音记录与生活管理:实用主义的数字生活
Immich (高性能计算相册) Immich 承担了整个照片管理与检索的核心工作,全面接管了原本由群晖负责的相册业务。群晖内置处理器在处理成千上万张历史照片的机器学习任务(如人脸识别、场景分类)时存在明显的算力瓶颈,长时间满负荷运行极易导致系统整体响应迟缓。将相册服务迁移至计算节点后,Immich 能够充分调度 12500T 的多核算力以及 32GB 内存,极速完成人脸聚类和照片质量评分。它的元数据库部署在 12500T 的本地高速固态硬盘中,而庞大的照片原文件则安全地存储于 28TB 的 iSCSI 网络挂载盘内。该服务内置的机器学习模型支持复杂的自然语言检索,大幅提升了海量历史图像数据的检索效率与管理可用性。
Compose 文件
version: "3.8"
services:
immich-server:
container_name: immich_server
image: ghcr.io/immich-app/immich-server:release
volumes:
- /data/Photos/library:/data # 核心照片库放在大硬盘
- /etc/localtime:/etc/localtime:ro
env_file:
- stack.env
ports:
- 2283:2283
depends_on:
- redis
- database
restart: always
immich-machine-learning:
container_name: immich_machine_learning
image: ghcr.io/immich-app/immich-machine-learning:release-openvino
device_cgroup_rules:
- 'c 189:* rmw'
devices:
- /dev/dri:/dev/dri
volumes:
- model-cache:/cache
- /dev/bus/usb:/dev/bus/usb
- /docker/immich/model-cache:/cache # 模型缓存建议留在系统 SSD
env_file:
- stack.env
restart: always
redis:
container_name: immich_redis
image: registry.hub.docker.com/library/redis:6.2-alpine
restart: always
database:
container_name: immich_postgres
image: ghcr.io/immich-app/postgres:14-vectorchord0.4.3
environment:
- POSTGRES_PASSWORD=${DB_PASSWORD}
- POSTGRES_USER=${DB_USERNAME}
- POSTGRES_DB=${DB_DATABASE}
volumes:
- /docker/immich/postgres:/var/lib/postgresql/data # 数据库留在系统 SSD
restart: always
Jellyfin (流媒体硬件编解码服务器) Jellyfin 在我的架构中被严格定义为生产力拉片工具,主要用于日常研究资料的审阅。我的工作流中需要频繁观看社会学访谈视频与民俗影像纪录片,这类资料通常阅后即删,无需建立庞大且冗余的本地影视库。Jellyfin 的核心优势在于能够直接调用 12500T 处理器内建的 UHD 770 核显进行高效的硬件解码。无论原始视频的编码格式或码率如何,它都能在服务器端进行实时转码,并将处理后的流媒体平滑推送到 iPad 或 MacBook 等终端设备上。转码产生的缓存文件直接写入主机的本地固态盘,确保了拖拽进度条时的极低延迟。这种机制有效避免了源文件占用终端设备存储,并支持多设备间的播放进度无缝同步,完全契合特定视频资料快速审阅与流转的使用场景。
Compose 文件
version: '3.8'
services:
jellyfin:
image: jellyfin/jellyfin:latest
container_name: jellyfin
user: 1000:1000 # 对应你的 PUID:PGID
network_mode: bridge
ports:
- 8096:8096
volumes:
- /docker/jellyfin/config:/config
- /docker/jellyfin/cache:/cache
- /data/Media:/media:ro # 大硬盘媒体库,只读挂载更安全
devices:
- /dev/dri:/dev/dri # 核心:Intel 核显直通
environment:
- TZ=Asia/Tokyo
- JELLYFIN_PublishedServerUrl=https:// #你的网址
restart: unless-stopped
Alist (多协议网盘资源聚合器) Alist 是一个支持多协议的公有云资源聚合工具。通过提供统一的 API 接口,它可以将百度网盘、阿里云盘、Google Drive 等多种不同平台的云端账号整合至同一个 Web 管理界面,并利用 WebDAV 协议将其映射为本地服务器上的标准文件目录。在与 Jellyfin 的协同工作流中,这一机制的效率优势尤为明显。我可以在 Alist 挂载的云盘目录中直接定位所需的视频资源,并交由 Jellyfin 读取播放。在整个流程中,视频数据流直接从云端节点经过计算服务器转发至播放终端,免去了事先将大体积视频文件下载至本地 28TB iSCSI 硬盘的繁琐步骤。这在物理存储总容量保持不变的前提下,通过网络协议的打通,大幅扩展了整个数字架构的可用数据范围。
Compose 文件
services:
alist:
image: 'xhofe/alist:latest'
container_name: alist
volumes:
- /docker/alist:/opt/alist/data
- /data/alist:/data:rw # 映射整个 iSCSI 挂载点,读写权限
ports:
- '5244:5244'
environment:
- PUID=1000
- PGID=1000
- UMASK=022
restart: always
Firefly III (复式财务记账系统) Firefly III 是一套支持复式记账的专业财务系统。在当前的电子支付环境下,个人的消费记录通常以碎片化的形式散落于各类应用程序中,形成缺乏关联的数字收据。部署 Firefly III 的主要目的是建立一套规范化的个人财务管理流程。该系统要求用户按照标准的财务准则,严格录入每一笔资金的来源、去向、关联账户及具体分类。系统数据库运行在 12500T 的本地存储中,确保了账单明细的高速读写。通过这种系统性的本地化托管应用,我能够将原本零散的开销数据进行结构化整合,自动生成多维度的财务报表。这种做法赋予了我对个人财务数据的绝对控制权,并在客观上帮助我定期审视并调整日常消费习惯,实现更为理性的个人资金管理与规划。
Compose 文件
version: '3.3'
services:
firefly-db:
image: mariadb:10
container_name: firefly-db
restart: always
environment:
- MYSQL_RANDOM_ROOT_PASSWORD=yes
- MYSQL_DATABASE=firefly
- MYSQL_USER=user
- MYSQL_PASSWORD=12345678 # 请修改密码
volumes:
- /docker/firefly/db:/var/lib/mysql
firefly-app:
image: fireflyiii/core:latest
container_name: firefly-app
restart: always
depends_on:
- firefly-db
environment:
- APP_KEY= <生成一个32位的随机英数字符串># 必须是32位
- DB_HOST=firefly-db
- DB_PORT=3306
- DB_CONNECTION=mysql
- DB_DATABASE=firefly
- DB_USERNAME=user
- DB_PASSWORD=12345678 # 需与上方一致
- TZ=Asia/Tokyo
- APP_URL=https://
- TRUSTED_PROXIES=**
volumes:
- /docker/firefly/export:/var/www/html/storage/export
- /docker/firefly/upload:/var/www/html/storage/upload
ports:
- "8089:8080"
4. 边缘探索与定制需求:针对特定场景的离线应用
Home Assistant (本地智能环境监控中枢) Home Assistant OS (HAOS) 在这套架构中主要承担环境数据监控与底层智能设备管理的职责。长崎夏季气候炎热,日常驻留大学研究室的时间较长,通过 HAOS 可以随时远程获取住所的实时温湿度曲线、网络路由器的流量状态,以及各类传感器回传的环境预警信息。在设备联动方面,HAOS 具备极强的跨平台协议兼容能力,能够将不同品牌的智能生态(如苹果 HomeKit 体系、小米生态链以及第三方独立传感器)统一接入本地化的控制面板。系统内部署的自动化逻辑完全基于本地局域网运行,各项指令处理均由 12500T 的算力独立完成。这意味着即使外部宽带网络出现异常,所有既定的环境控制和监测规则依然能够稳定生效,极大地提升了居住环境管理的高度可靠性。
Compose 文件
version: '3.8'
services:
homeassistant:
container_name: homeassistant
image: "ghcr.io/home-assistant/home-assistant:stable"
volumes:
- /docker/homeassistant:/config
- /etc/localtime:/etc/localtime:ro
- /run/dbus:/run/dbus:ro # 蓝牙通信必须挂载 dbus
restart: unless-stopped
privileged: true # 赋予特权模式以访问无线网卡和蓝牙硬件
network_mode: host # 必须使用 Host 模式,否则无线发现功能无效
OpenWebUI (私有化大语言模型终端) 在本地部署 OpenWebUI 主要是为了应对两项具体的计算需求。首先,日常的社会学研究中会产生大量零散且未清洗的文献资料,需要借助大语言模型进行初步的信息提取与结构化处理。将此类庞大且高频的文本处理任务交由本地模型运行,能够有效规避长期调用商业 API 所产生的高昂计费。在此场景下,本地模型只需输出速度覆盖日常阅读速度即可满足初步信息过滤的需求。其次,在业余的小说创作中,我需要构建独立的交互环境来测试角色的设定逻辑。通过向模型输入角色背景并进行多轮对话,可以检验人物在经历特定剧情后性格发展的一致性。这种涉及大量未公开设定的语料库,离线运行能够确保数据隐私的绝对安全。针对 12500T 处理器在执行大模型推理时的算力限制,后续计划引入一台功耗控制在 100W 以内的专用计算节点来独立承载此类工作负载。
Compose 文件
version: '3.8'
services:
open-webui:
image: ghcr.io/open-webui/open-webui:main
container_name: open-webui
restart: unless-stopped
ports:
- '8080:8080'
volumes:
- /docker/open-webui:/app/backend/data
environment:
# 关闭本地 Ollama 自动连接,节省资源
- 'ENABLE_OLLAMA=False'