2、游戏服务器Docker化：单体游戏服务器容器化改造、多阶段构建优化镜像体积、环境变量与配置管理

好，咱们进入正题。这一章聊的是游戏服务器Docker化，说白了就是把我们传统的单体游戏服务器，塞进Docker容器里跑起来。

你可能会问：为什么要费这个劲？我直接部署在物理机上不也挺好？嗯，我在早期项目里也是这么想的。直到有一次线上扩容，运维同学手动配环境配了整整一个通宵……从那以后，我再也不敢轻视容器化这件事了。

2.1 单体游戏服务器的容器化改造

先说说单体游戏服务器。很多老项目，尤其是MMO类型的，都是一个巨大的进程搞定所有事：网络连接、逻辑处理、数据存储、甚至还有AI模块。这种架构在容器化时，其实比微服务要简单——因为你就一个进程要管。

但简单归简单，坑也不少。我个人的习惯是，先理清楚三个问题：

  • 进程怎么跑——启动命令、依赖库、运行时环境
  • 数据怎么存——日志、配置、玩家数据，哪些该进容器，哪些不该
  • 网络怎么通——端口映射、内网通信、对外暴露

举个例子，假设我们有一个C++写的游戏服务器，编译产物是一个叫 gameserver 的二进制文件。传统部署方式下，运维会在机器上装好依赖库，然后手动启动。容器化之后，我们只需要写一个Dockerfile：

FROM ubuntu:20.04

RUN apt-get update && apt-get install -y \
    libssl-dev \
    libcurl4-openssl-dev \
    && rm -rf /var/lib/apt/lists/*

COPY gameserver /usr/local/bin/
COPY config.toml /etc/gameserver/

EXPOSE 8888

CMD ["gameserver", "-c", "/etc/gameserver/config.toml"]

你看，就这么简单。但这里有个细节：COPY config.toml 这一步，我建议把配置文件和二进制分开。为什么？因为配置经常改，而二进制很少改。分开之后，你可以只重新部署配置，不用重新构建整个镜像。

小技巧： 把配置文件和日志目录挂载到宿主机，这样容器重启后数据不会丢。我习惯用 -v /data/game/config:/etc/gameserver 这种方式。

2.2 多阶段构建：把镜像体积瘦下来

镜像体积这件事，一开始我根本没在意。直到有一次，我构建了一个1.2GB的镜像，传到私有仓库花了快10分钟……团队成员都在等我。嗯，从那以后，我开始认真研究怎么瘦身。

多阶段构建（Multi-stage Build）就是干这个的。它的核心思想是：编译环境和运行环境分开。编译阶段用大而全的基础镜像，运行阶段只保留最小的运行时依赖。

来看一个实际例子。假设我们的游戏服务器是用Go写的，编译时需要gcc、make、各种头文件，但运行时只需要一个裸的二进制：

# 第一阶段：编译
FROM golang:1.21 AS builder

WORKDIR /app
COPY . .
RUN go mod download
RUN CGO_ENABLED=0 GOOS=linux go build -o gameserver .

# 第二阶段：运行
FROM alpine:3.19

RUN apk add --no-cache ca-certificates tzdata

COPY --from=builder /app/gameserver /usr/local/bin/
COPY config.yaml /etc/gameserver/

EXPOSE 8888

CMD ["gameserver", "-c", "/etc/gameserver/config.yaml"]

你看，最终镜像只有几十MB。为什么？因为alpine本身很小，而且我们只复制了编译好的二进制和配置文件。那些编译工具、依赖库，全都被留在了第一阶段。

构建方式 镜像大小 构建时间 安全性
单阶段（ubuntu） ~800MB 快 低（包含多余工具）
多阶段（alpine） ~50MB 稍慢（编译阶段） 高（最小化攻击面）
注意： 使用alpine时要注意，它的C库是musl而不是glibc。如果你的游戏服务器依赖了某些glibc特有的功能，可能会出问题。我曾经踩过这个坑——一个用C++写的服务器，在alpine上跑起来就段错误，查了半天才发现是musl的线程局部存储实现不一样。

2.3 环境变量与配置管理

容器化之后，配置管理的方式也得变一变。以前我们可能直接在代码里写死配置，或者从本地文件读取。但在容器环境里，尤其是Kubernetes下，配置应该是动态的、可注入的。

我个人推荐的做法是：环境变量 + 配置文件模板。环境变量用来控制那些经常变的东西，比如数据库地址、日志级别、服务器ID。配置文件模板则用来定义那些相对固定的结构。

举个例子，我们的游戏服务器启动时需要知道：

  • DB_HOST —— 数据库地址
  • DB_PORT —— 数据库端口
  • LOG_LEVEL —— 日志级别
  • SERVER_ID —— 服务器编号

在Dockerfile里，我们可以这样处理：

FROM alpine:3.19

COPY gameserver /usr/local/bin/
COPY config.template.yaml /etc/gameserver/

# 使用entrypoint脚本，在启动时替换环境变量
COPY entrypoint.sh /entrypoint.sh
RUN chmod +x /entrypoint.sh

ENTRYPOINT ["/entrypoint.sh"]
CMD ["gameserver", "-c", "/etc/gameserver/config.yaml"]

entrypoint.sh的内容大致是：

#!/bin/sh
set -e

# 替换配置文件中的环境变量占位符
envsubst < /etc/gameserver/config.template.yaml > /etc/gameserver/config.yaml

# 执行主进程
exec "$@"

而config.template.yaml里，我们这样写：

server:
  id: ${SERVER_ID:-1}
  log_level: ${LOG_LEVEL:-info}

database:
  host: ${DB_HOST:-localhost}
  port: ${DB_PORT:-3306}

你看，这样启动容器时，只需要传入环境变量：

docker run -e SERVER_ID=2 -e DB_HOST=10.0.0.1 -e LOG_LEVEL=debug my-game-server:latest
核心原则： 镜像应该是不可变的，配置应该是可变的。同一个镜像，通过不同的环境变量，可以部署出不同的服务器实例。这就是云原生的精髓之一。

最后说一句，环境变量虽然方便，但别把所有东西都塞进去。敏感信息比如数据库密码，我建议用Docker Secrets或者Kubernetes Secrets来管理。直接在环境变量里写明文密码？嗯，我见过有人这么干，结果代码不小心传到GitHub上……你懂的。

好了，这一章的内容就到这里。下一章我们会聊聊如何用Docker Compose编排多个游戏服务器，以及如何做服务发现。到时候见。

← 上一章 📖 返回目录 下一章 →