1. 为什么用Docker跑WOW服务端

把WOW服务端塞进Docker里跑，这个念头最早来自我自己的一个痛点：每次换机器或者重装系统，服务端环境就得从头来一遍，MySQL版本不对、依赖库缺失、配置文件路径写死，折腾一圈下来半天就没了。后来我把整套东西容器化之后，迁移只需要拷贝一个目录，docker compose up -d就完事，这种体验上的差距是实打实的。

WOW服务端本质上是一个C++编写的大型网络服务程序，它需要数据库支撑（通常是MySQL或MariaDB）、需要特定的运行库、需要开放多个端口给客户端连接。传统部署方式下，这些东西全部耦合在宿主机上，一旦某个环节出问题，排查起来非常痛苦。Docker的价值就在于把这些组件拆成独立的容器，每个容器只负责一件事，通过网络互相通信，出了问题也能快速定位是哪个环节的毛病。

这篇文章适合几类人看：一是有一定Linux基础、想自己搭个WOW服务端玩玩的朋友；二是已经在用传统方式部署、想迁移到容器化方案的老玩家；三是对Docker感兴趣、想拿一个真实项目练手的运维新手。不管你属于哪一类，我都会把每一步的操作意图和背后的逻辑讲清楚，让你不只是照抄命令，而是真正理解自己在做什么。

需要提前说明的是，WOW服务端有很多分支版本，不同版本对数据库结构、配置文件格式的要求差异很大。我这里以最常见的AzerothCore架构为例来展开，它的社区活跃度高、文档相对完善、容器化支持也比较好。如果你用的是TrinityCore或其他分支，思路是一样的，具体配置项需要对照对应版本的文档调整。

2. 整体架构设计与组件拆解

2.1 容器划分逻辑

一套完整的WOW服务端至少需要三个核心组件：认证服务、世界服务和数据库。认证服务负责处理客户端登录请求，验证账号密码；世界服务负责游戏内的所有逻辑，包括角色移动、战斗、任务、NPC行为等等；数据库则存储账号信息、角色数据、世界数据（怪物刷新、物品掉落、任务定义等）。

在Docker方案下，我建议把这三大组件拆成独立的容器。认证服务和世界服务可以共用同一个镜像（因为它们来自同一套代码编译产物），但运行不同的入口程序。数据库单独使用官方MySQL镜像或MariaDB镜像。这样做的好处是：数据库可以独立备份和恢复，世界服务崩溃了不影响认证服务，升级某个组件时不需要动其他部分。

容器之间的通信通过Docker自定义网络实现。创建一个bridge网络，把三个容器都接进去，它们就可以通过容器名互相访问。比如世界服务的配置文件里写数据库地址时，直接写数据库容器的名字就行，Docker内置的DNS会自动解析。这比用IP地址靠谱得多，因为容器重启后IP可能会变，但容器名是固定的。

2.2 数据持久化方案

容器本身是无状态的，删掉重建后里面的数据就没了。但数据库里的账号、角色、世界数据显然不能丢，所以必须做持久化。Docker提供了volume和bind mount两种方式，我个人更倾向于bind mount，也就是把宿主机上的一个目录挂载到容器内部。原因很简单：备份的时候直接拷贝宿主机目录就行，不需要去记volume的名字，也不需要用docker volume inspect去查路径。

具体来说，我会在宿主机上创建一个目录结构，比如/opt/wow/data/mysql用来存数据库文件，/opt/wow/data/world用来存世界服务的日志和持久化数据，/opt/wow/etc用来存配置文件。然后通过volumes指令把这些目录映射到容器内的对应路径。这样即使把容器全部删掉，只要这些目录还在，重新up一下就能恢复如初。

注意：MySQL容器对数据目录的权限有要求，如果宿主机目录的属主不对，容器启动时会报权限错误。建议先把目录属主改成999（MySQL容器内mysql用户的UID），或者用chmod 777临时放开权限测试，确认没问题后再收紧。

2.3 镜像来源选择

WOW服务端的镜像有两种获取方式：自己编译和用社区现成的。自己编译的好处是可控性强，可以针对自己的CPU架构做优化，也能确保代码是最新的；坏处是编译过程比较耗时，而且需要一定的C++编译环境知识。社区现成镜像的好处是开箱即用，省去了编译环节；坏处是版本可能滞后，而且你不太清楚里面到底装了什么。

我的建议是：第一次搭建先用社区镜像跑通流程，熟悉整个架构之后再尝试自己编译。AzerothCore官方在Docker Hub上有维护镜像，可以直接拉取。如果你用的是ARM架构的设备（比如某些开发板），需要注意镜像是否支持多架构，不支持的话就得自己编译。

3. 环境准备与Docker安装要点

3.1 操作系统选择与基础配置

跑WOW服务端对系统资源有一定要求。内存方面，数据库加两个服务进程，至少需要4GB可用内存，8GB以上会比较从容。CPU方面，现代双核处理器就能跑起来，但如果要支持较多玩家同时在线，核心数越多越好。磁盘方面，服务端程序本身不大，但数据库和日志会持续增长，建议预留至少20GB空间。

操作系统我推荐Ubuntu 22.04 LTS或Debian 12，这两个发行版的Docker支持最完善，社区文档也最丰富。如果你用的是CentOS 7，需要注意它的内核版本较老，某些Docker新特性可能不支持，而且CentOS 7已经停止维护，长远来看建议迁移到其他发行版。

安装Docker本身不复杂，但有几个关键点容易踩坑。首先是安装源的选择，官方源速度慢的话可以换国内镜像源，但要注意镜像源的可靠性。其次是安装后的权限配置，默认情况下只有root用户能执行docker命令，普通用户需要加入docker组。执行sudo usermod -aG docker $USER之后需要重新登录才能生效，这个步骤经常被忽略。

3.2 Docker与Docker Compose安装实操

在Ubuntu上安装Docker的完整流程如下。先更新包索引并安装必要的依赖：

sudo apt update sudo apt install -y ca-certificates curl gnupg lsb-release

然后添加Docker官方GPG密钥和软件源：

sudo mkdir -p /etc/apt/keyrings curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

接下来安装Docker引擎和Compose插件：

sudo apt update sudo apt install -y docker-ce docker-ce-cli containerd.io docker-compose-plugin

安装完成后验证一下：

sudo docker run hello-world

如果能看到欢迎信息，说明Docker安装成功。Compose插件现在通常以docker compose（注意中间是空格）的形式调用，而不是老版本的docker-compose。两者功能基本一致，但插件方式更推荐。

提示：如果你在Windows上想用Docker Desktop来跑，需要确保BIOS里开启了虚拟化支持。很多品牌机默认是关闭的，开机时按F2或Del进入BIOS设置，找到Intel VT-x或AMD-V选项开启即可。开启后Docker Desktop才能正常启动。

3.3 目录结构规划

在开始写Compose文件之前，先把目录结构规划好。我习惯用这样的布局：

/opt/wow/ ├── docker-compose.yml ├── etc/ │ ├── worldserver.conf │ └── authserver.conf ├── data/ │ ├── mysql/ │ └── world/ └── logs/ ├── worldserver/ └── authserver/

这个结构清晰地把配置、数据、日志分开存放。etc目录挂载到容器内对应配置文件的位置，data/mysql挂载到数据库容器的数据目录，data/world和logs挂载到世界服务容器的相应路径。这样无论是备份还是排查问题，都能快速找到需要的东西。

创建目录的命令很简单：

sudo mkdir -p /opt/wow/{etc,data/mysql,data/world,logs/worldserver,logs/authserver}

权限方面，数据库目录需要特殊处理，其他目录保持默认即可。

4. 核心配置文件编写与参数详解

4.1 Docker Compose编排文件

Compose文件是整个方案的核心，它定义了所有容器的运行方式、网络关系、挂载点和依赖顺序。下面是我实际使用的一个配置模板，你可以根据自己的情况调整：

version: '3.8' services: mysql: image: mysql:8.0 container_name: wow-mysql restart: unless-stopped environment: MYSQL_ROOT_PASSWORD: your_root_password MYSQL_DATABASE: acore_world MYSQL_USER: acore MYSQL_PASSWORD: your_acore_password volumes: - ./data/mysql:/var/lib/mysql networks: - wow-net command: --default-authentication-plugin=mysql_native_password --character-set-server=utf8mb4 --collation-server=utf8mb4_unicode_ci authserver: image: azerothcore/authserver:latest container_name: wow-auth restart: unless-stopped depends_on: - mysql volumes: - ./etc/authserver.conf:/azerothcore/env/dist/etc/authserver.conf - ./logs/authserver:/azerothcore/env/dist/bin/logs ports: - "3724:3724" networks: - wow-net worldserver: image: azerothcore/worldserver:latest container_name: wow-world restart: unless-stopped depends_on: - mysql volumes: - ./etc/worldserver.conf:/azerothcore/env/dist/etc/worldserver.conf - ./data/world:/azerothcore/env/dist/bin/data - ./logs/worldserver:/azerothcore/env/dist/bin/logs ports: - "8085:8085" networks: - wow-net networks: wow-net: driver: bridge

这个文件里几个关键点值得展开说。restart: unless-stopped保证容器在意外退出后自动重启，除非你手动停了它。depends_on控制启动顺序，确保数据库先起来再启动服务端。端口映射方面，3724是认证端口，8085是世界端口，客户端连接时需要用到。

4.2 数据库初始化与导入

MySQL容器第一次启动时会自动创建MYSQL_DATABASE指定的数据库，但WOW服务端需要的表结构和初始数据不会自动导入。你需要手动把服务端的SQL文件导入进去。AzerothCore的SQL文件通常分为三类：基础结构、世界数据、更新补丁。

导入的方式有几种。一种是在宿主机上安装MySQL客户端，通过mysql -h 127.0.0.1 -P 3306 -u root -p连接容器内的数据库然后执行SQL文件。另一种是直接用docker exec进入容器操作：

docker exec -i wow-mysql mysql -uroot -pyour_root_password acore_world < /path/to/world.sql

导入之前要确保数据库字符集是utf8mb4，否则中文内容会乱码。Compose文件里已经通过command参数设置了，但如果你用的是已有的数据库，需要手动检查一下。

注意：导入大型SQL文件时可能会遇到max_allowed_packet限制，导致导入中断。可以在MySQL配置里把这个值调大，比如设为64M或128M。在Compose的command里加上--max-allowed-packet=128M即可。

4.3 服务端配置文件关键项

worldserver.conf和authserver.conf是服务端的核心配置文件，里面有几百个参数，但真正需要改的没几个。最关键的是数据库连接信息，必须和Compose里定义的一致：

LoginDatabaseInfo = "wow-mysql;3306;acore;your_acore_password;acore_auth" WorldDatabaseInfo = "wow-mysql;3306;acore;your_acore_password;acore_world" CharacterDatabaseInfo = "wow-mysql;3306;acore;your_acore_password;acore_characters"

注意这里的主机名写的是容器名wow-mysql，因为它们在同一个Docker网络里，DNS可以直接解析。如果你把数据库换成了外部地址，这里也要相应修改。

另外几个值得关注的参数：WorldServerPort默认是8085，如果你宿主机上这个端口被占用了，需要改掉；DataDir指向数据目录，确保和volume挂载的路径一致；LogsDir指向日志目录。还有AllowPlayerBots之类的玩法参数，根据自己需求调整。

5. 启动流程与验证方法

5.1 分步启动与日志观察

一切就绪后，在/opt/wow目录下执行：

docker compose up -d

这个命令会按依赖顺序启动所有容器。启动完成后用docker compose ps查看状态，正常情况下三个容器的状态都应该是Up。如果某个容器显示Exit或Restarting，就需要看日志排查。

查看日志的命令是docker compose logs -f 服务名，比如docker compose logs -f worldserver。世界服务的启动过程比较长，因为它要加载大量的地图数据和AI脚本，第一次启动可能需要几分钟。日志里会显示加载进度，看到World initialized之类的字样就说明启动成功了。

认证服务的启动相对快一些，日志里出现Authserver listening on port 3724就表示正常。数据库容器启动最快，但要注意它初始化需要一点时间，如果服务端启动时数据库还没准备好，可能会连接失败。depends_on只能保证启动顺序，不能保证数据库已经初始化完成，所以第一次启动时如果服务端报连接错误，等一会儿重启一下服务端容器就行。

5.2 连通性测试

服务端跑起来之后，先在本机测试一下端口是否可达：

telnet 127.0.0.1 3724 telnet 127.0.0.1 8085

如果连接被拒绝，说明端口没有正确映射或者服务没有监听。可以用docker compose port authserver 3724查看实际映射的端口。如果宿主机有防火墙，还需要放行这两个端口。

数据库连通性可以用docker exec wow-mysql mysql -uacore -p -e "SHOW DATABASES;"来测试，能看到acore_auth、acore_world、acore_characters三个库就说明正常。

5.3 客户端连接配置

客户端这边需要修改realmlist.wtf文件，把地址指向你的服务器IP。如果是局域网内测试，填宿主机的局域网IP即可；如果是公网访问，需要填公网IP并确保端口映射正确。客户端的版本必须和服务端匹配，比如服务端是3.3.5a版本，客户端也必须是3.3.5a，版本不对会卡在登录界面或者直接报错。

登录时用服务端数据库里创建的账号。如果还没有账号，可以通过世界服务的控制台命令创建，或者直接在acore_auth库的account表里插入一条记录。密码字段需要用特定的哈希算法生成，不能直接存明文。

6. 常见问题排查与避坑经验

6.1 容器启动失败类问题

数据库容器反复重启，最常见的原因是数据目录权限不对。MySQL容器内的mysql用户UID通常是999，如果宿主机目录属主不是999，容器就无法写入。解决办法是sudo chown -R 999:999 /opt/wow/data/mysql。另一个原因是之前残留的数据文件版本不兼容，比如从MySQL 5.7升级到8.0，数据格式不兼容。这种情况需要清空数据目录重新初始化。

服务端容器启动后立即退出，大概率是配置文件有问题。用docker compose logs worldserver看具体报错，常见的有：数据库连接信息错误、配置文件路径不对、数据目录为空。如果是数据目录为空，说明地图数据没有正确挂载或没有导入，需要检查volume映射路径。

端口被占用导致启动失败，用ss -tlnp | grep 3724查看哪个进程占用了端口，停掉它或者修改Compose里的端口映射。

6.2 运行时报错类问题

服务端启动时报数据库连接超时，如果数据库容器刚启动不久，可能是还没初始化完成。等30秒后重启服务端容器即可。如果一直连不上，检查Compose里的网络配置，确保两个容器在同一个network下。可以用docker exec wow-world ping wow-mysql测试网络连通性。

客户端登录后卡在“正在连接”或“已断开”，通常是端口映射或防火墙问题。确认3724和8085端口在宿主机上可达，如果是云服务器，还需要检查安全组规则。另外，服务端配置文件里的RealmIP如果写的是内网地址，外网客户端就连不上，需要改成公网地址或者用域名。

游戏内中文显示乱码，说明数据库字符集不对。检查数据库、表和连接三个层面的字符集设置，确保都是utf8mb4。已经导入的数据如果乱码了，需要重新导入。

6.3 性能与稳定性问题

服务端运行一段时间后变卡，可能是数据库查询变慢或者内存泄漏。先看docker stats确认哪个容器占用资源异常。数据库方面可以开启慢查询日志，找出耗时长的SQL。世界服务方面，定期重启可以缓解内存泄漏问题，用restart: unless-stopped配合定时任务就能实现。

玩家数量多时延迟高，考虑给世界服务容器分配更多CPU和内存资源。在Compose里可以用deploy.resources限制或预留资源，但注意这个配置在非Swarm模式下只有部分生效。更直接的方式是调整宿主机的资源分配，或者把数据库迁移到独立的高性能机器上。

6.4 常见问题速查表

7. 数据备份与版本升级策略

7.1 数据库备份实操

数据库是整个服务端最宝贵的资产，角色数据丢了就全没了。备份方式我推荐用mysqldump导出SQL文件，简单可靠：

docker exec wow-mysql mysqldump -uroot -pyour_root_password --all-databases > /opt/wow/backup/all_$(date +%Y%m%d).sql

这个命令把所有数据库导出到一个SQL文件里，文件名带日期方便管理。恢复的时候用docker exec -i wow-mysql mysql -uroot -p < backup.sql即可。建议写个定时任务每天自动备份，并且把备份文件同步到另一台机器或对象存储上，防止宿主机磁盘故障导致备份一起丢失。

提示：mysqldump导出时会锁表，如果服务端正在运行，可能会造成短暂的卡顿。可以在低峰期执行，或者加上--single-transaction参数减少锁的影响。

7.2 服务端版本升级

升级服务端版本时，不能直接把新镜像拉下来就重启，因为数据库结构可能发生了变化。正确的流程是：先备份数据库，然后查看新版本的更新说明，确认是否有数据库迁移脚本需要执行。执行完迁移脚本后再更新镜像和重启容器。

如果升级后出现问题需要回滚，把镜像标签改回旧版本，恢复数据库备份即可。这也是为什么我强调要用固定版本标签而不是latest，因为latest随时可能变，出了问题很难定位是哪个版本引入的。

7.3 配置文件版本管理

配置文件也建议纳入版本管理，用Git或者简单的文件备份都行。每次修改配置前先备份一份，改完之后记录改了什么、为什么改。这样出问题时可以快速对比和回滚。我自己的习惯是在/opt/wow/etc目录下建一个backup子目录，每次改配置前把旧文件复制进去并加上时间戳。

8. 我踩过的几个坑和实用技巧

第一个坑是数据库字符集。我一开始没注意，用默认的latin1建库，结果所有中文NPC名字和任务描述全是问号。后来把数据库、表和连接字符集全部改成utf8mb4才解决。这个问题的隐蔽性在于，英文内容完全正常，只有中文才出问题，所以很容易被忽略。

第二个坑是容器时间不同步。WOW服务端有些功能依赖系统时间，比如日常任务重置、怪物刷新计时等。如果容器时间和宿主机不一致，这些功能就会出问题。解决办法是在Compose文件里把宿主机的/etc/localtime挂载到容器内，或者设置TZ环境变量。

第三个坑是日志文件无限增长。世界服务的日志非常详细，运行几天就能涨到几个GB。如果不做日志轮转，磁盘很快就会被占满。我现在的做法是在Compose里限制日志大小，或者用logrotate定期清理。Docker本身的日志也可以限制，在daemon.json里配置max-size和max-file。

一个实用技巧是善用docker compose exec进入容器排查问题。比如docker compose exec worldserver bash进去之后，可以直接查看文件、测试网络、运行调试命令，比在宿主机上猜要高效得多。另一个技巧是把常用命令写成脚本，比如启动、停止、备份、查看日志，一键执行，省去每次敲长命令的麻烦。

最后分享一个关于性能调优的经验：世界服务的性能瓶颈通常在数据库查询上。如果发现游戏内操作有延迟，可以先看数据库的慢查询日志。给常用查询字段加索引、优化复杂的JOIN语句，往往能带来明显的提升。另外，把数据库的innodb_buffer_pool_size调大，让更多数据缓存在内存里，对性能也有帮助。这个值一般设为可用内存的50%到70%比较合适。