Day: January 17, 2026

本文记录一次将 原生安装的《饥荒联机版（DST）》专用服务器 平滑迁移至 Docker 容器环境 的全过程。重点不在“如何一键搭建”，而在 配置复用、端口一致性、MOD 自动管理、Shard 分片通信验证 等关键细节。 一、迁移背景与目标 原服务器为 原生 Linux 安装 的 DST Dedicated Server，运行多年，具有以下特点： 迁移目标不是“重装”，而是： 在 Docker 中完整接管运行环境，但不破坏任何已有数据结构与行为逻辑。 核心原则： 二、整体目录结构设计（脱敏示意） 宿主机统一使用一个工作目录： 关键说明： 三、Docker 镜像选择与原则 使用的镜像类型： 原则： Docker 只负责“跑”，不负责“改”。 因此明确禁止镜像行为： 四、Docker Compose 设计要点（概念说明） 1️⃣ 使用 host 网络模式 原因： 👉 所有端口直接由 ini 文件控制 2️⃣ Master / Caves …

一、写在最前面：为什么要“认真”跑一个游戏服务器 很多教程的目标只有一句话： “服务器能跑，能进就行。” 但在真实服务器环境中，这种目标是不够的。 本次实践的目标从一开始就明确为： 这不是“为了折腾”，而是为了避免后期不可控成本。 二、总体设计思想 1. 核心分离原则 在本方案中，Palworld 服务被拆成三层： 层级 角色 处理方式 世界数据 核心资产 永久保存在宿主机 配置文件 行为定义 由管理员手动维护 容器 执行外壳 可随时删除 一句话总结： 世界不属于容器，容器只是世界的“临时执行环境”。 三、目录结构设计（完全脱敏） 以下为逻辑结构示意，非真实路径： 关键点说明 四、Docker Compose 的设计原则（而不是参数堆砌） 1. 镜像使用原则 原因很简单： 运行环境应尽量无状态、无外部依赖 2. 环境变量的克制使用 在 compose 中： 这样做的好处是： 3. 禁止自动生成 / 覆盖配置 明确禁止镜像在启动时： 这是防止世界“被重置”的关键步骤之一。 五、端口策略（完全脱敏说明） 1. 对外端口原则 …