1. 项目概述：告别虚拟机，拥抱容器化部署

如果你是一名Unity游戏开发者，并且你的游戏需要发布Linux服务器版本，那么你很可能经历过这样的痛苦：在Windows或macOS的开发机上，为了构建和测试Linux版本，不得不安装一个笨重的虚拟机。每次构建都要切换环境，配置依赖，不仅耗时，还常常因为环境差异导致“在我机器上能跑，在服务器上就崩了”的尴尬局面。更别提后续的部署环节，手动上传文件、配置权限、启动服务，每一步都充满了不确定性。

这个项目标题“Unity游戏发布Linux版，别再只靠虚拟机了！试试Docker一键部署（附完整脚本）”精准地戳中了这个痛点。它提出的解决方案核心，就是用Docker容器技术，彻底取代传统的虚拟机工作流。Docker不是虚拟机，它是一个轻量级的应用容器引擎，可以将你的应用及其所有依赖（包括运行时、系统工具、库、设置）打包成一个标准化的单元，即“镜像”。这个镜像可以在任何安装了Docker的Linux系统上，以完全一致的方式运行起来。

为什么这比虚拟机好？虚拟机模拟的是完整的操作系统，需要分配固定的CPU、内存和存储资源，启动慢、占用大。而Docker容器直接共享宿主机的操作系统内核，因此极其轻量，启动速度以秒计，资源开销极小。对于游戏服务器部署来说，这意味着更快的启动时间、更高的资源利用率和更一致的运行环境。

这篇文章，我将以一个资深游戏后端开发者的视角，带你从零开始，手把手将你的Unity游戏服务器构建成Docker镜像，并编写一个强大的Shell脚本，实现从构建、打包到部署的“一键化”操作。无论你是独立开发者还是团队协作，这套流程都能极大提升效率，确保环境一致性。我们不仅会讲“怎么做”，更会深入剖析“为什么这么做”，并分享我在实际项目中踩过的坑和总结的经验。

2. 核心思路与方案选型：为什么是Docker + Shell脚本？

在决定采用Docker之前，我们需要理清几种常见的Linux部署方案，并理解Docker方案的优势所在。

2.1 传统部署方案的痛点分析

  1. 虚拟机方案 ：如前所述，资源消耗大，环境隔离过于“厚重”，镜像文件动辄几个GB，传输和启动都慢。更重要的是，虚拟机内的环境（如特定版本的glibc）可能与最终的生产服务器仍有差异。
  2. 直接编译部署 ：在开发机上交叉编译出Linux二进制文件，然后通过SCP/FTP上传到服务器。这种方式最不可控，因为你的开发机环境（库版本、路径）与生产服务器几乎不可能完全一致，极易引发运行时链接库缺失（如 libicu 、特定版本的 libstdc++ ）或符号未定义错误。
  3. 持续集成/持续部署（CI/CD）工具 ：如Jenkins、GitLab CI等。这确实是更高级的解决方案，但对于小型项目或个人开发者来说，搭建和维护一套CI/CD流水线有一定门槛，且配置复杂。

2.2 Docker方案的优势

Docker方案完美解决了上述痛点：

  • 环境一致性 ： Dockerfile 定义了构建镜像的每一步操作，确保了从开发到测试再到生产，运行环境100%一致。“构建一次，到处运行”是其核心承诺。
  • 轻量高效 ：容器共享宿主机内核，无需启动完整的操作系统，使得镜像体积小（通常只有几百MB），启动速度快（秒级）。
  • 资源隔离 ：容器之间以及容器与宿主机之间是隔离的，你的游戏服务器进程不会影响宿主机的其他服务，安全性更好。
  • 易于版本管理与回滚 ：每个Docker镜像都有唯一的标签（Tag），你可以轻松地部署v1.0.0版本，如果发现问题，立刻回滚到上一个稳定版本v0.9.0。
  • 标准化交付 ：Docker镜像成为了交付的标准单元，无论是交给测试人员，还是部署到云服务器，操作都是一样的。

2.3 为什么搭配Shell脚本？

Docker本身提供了命令行工具（ docker build , docker run ），但手动输入一系列命令容易出错，且不便于重复执行和自动化。Shell脚本的作用就是将这一系列离散的命令组织成一个连贯的、可配置的自动化流程。

我们的“一键部署脚本”将实现以下功能：

  1. 参数化 ：允许通过命令行参数或配置文件指定游戏名称、版本号、构建目标等。
  2. 流程串联 ：自动执行Unity命令行构建、Docker镜像构建、打标签、上传到镜像仓库（可选）、在服务器上拉取并运行容器。
  3. 错误处理 ：在关键步骤（如构建失败、镜像已存在）进行判断和提示，增强健壮性。
  4. 日志记录 ：将构建和部署过程中的关键信息输出到日志文件，便于排查问题。

注意 ：本文的方案主要针对**无图形界面的Unity游戏服务器（Headless Server）**的构建与部署。对于需要图形渲染的Linux客户端游戏，Docker部署会涉及更复杂的图形驱动透传（如使用 --gpus all 和X11转发），不在本文主要讨论范围，但核心的容器化思想是相通的。

3. 环境准备与核心工具链详解

工欲善其事，必先利其器。在开始之前，我们需要确保本地开发环境和目标服务器环境都已就绪。

3.1 本地开发环境配置

1. Unity编辑器与Linux构建模块 这是最基本的前提。你需要安装Unity Hub和所需的Unity编辑器版本。

  • 打开Unity Hub，进入 安装 选项卡，找到你项目使用的Unity版本，点击右侧的三个点，选择 添加模块 。
  • 在弹出的列表中， 必须勾选 Linux Build Support (Mono) 或 Linux Build Support (IL2CPP) 。对于服务器，通常选择Mono后端即可，它构建更快。IL2CPP能提供更好的性能和安全性，但构建时间更长。同时，强烈建议勾选 Linux Dedicated Server Build Support ，这个模块包含了构建无头服务器所需的特定组件和模板。

2. Docker Desktop / Docker Engine

  • Windows/macOS用户 ：推荐安装 Docker Desktop 。它提供了一个图形化界面，并集成了Docker CLI。安装后务必启动Docker服务。
  • Linux用户 ：直接安装Docker Engine即可，例如在Ubuntu上使用 sudo apt-get install docker.io 。
  • 验证安装 ：打开终端（或PowerShell、Command Prompt），运行 docker --version 和 docker run hello-world 。如果能看到版本信息并成功运行hello-world容器，说明Docker安装成功。

3. 项目结构准备 确保你的Unity项目已经配置好服务器构建场景和网络逻辑。通常，你需要一个独立的、不包含任何客户端UI逻辑的场景作为服务器的启动场景，并在 File -> Build Settings 中将其添加到场景列表。

3.2 服务器环境配置（目标Linux机器）

你的游戏最终要运行在云服务器（如阿里云ECS、腾讯云CVM）或物理Linux主机上。

  • 操作系统 ：推荐Ubuntu 20.04 LTS或22.04 LTS，社区支持好，资料丰富。
  • Docker Engine ：必须在服务器上安装Docker。安装命令与本地Linux类似。
  • 网络与安全组 ：确保服务器的防火墙（如 ufw ）或云服务商的安全组规则，开放了你的游戏服务器需要监听的端口（例如UDP 7777）。

3.3 编写Dockerfile：构建镜像的蓝图

Dockerfile 是构建Docker镜像的指令文件，是整个过程的核心。我们将在Unity项目根目录下创建一个 Dockerfile 。

# 使用一个轻量级的Linux运行时作为基础镜像，推荐使用Ubuntu LTS版本
FROM ubuntu:22.04

# 设置非交互式前端，避免apt-get安装时等待用户输入
ENV DEBIAN_FRONTEND=noninteractive

# 安装游戏服务器可能需要的运行时依赖
# 例如：一些Unity游戏可能需要libicu、ca-certificates等
RUN apt-get update && \
    apt-get install -y --no-install-recommends \
        libicu70 \
        ca-certificates \
        libgssapi-krb5-2 \
        libssl3 \
        && \
    rm -rf /var/lib/apt/lists/* # 清理缓存，减小镜像体积

# 创建一个非root用户来运行应用，增强安全性
RUN useradd -m -u 1000 unityserver
USER unityserver
WORKDIR /app

# 将构建好的Linux服务器文件复制到镜像中
# 假设Unity构建输出到项目根目录的 `Builds/LinuxServer/` 文件夹
COPY --chown=unityserver:unityserver Builds/LinuxServer/. ./

# 暴露游戏服务器监听的端口（例如UDP 7777）
# 注意：EXPOSE只是一个声明，实际映射需要在运行容器时通过 `-p` 参数完成
EXPOSE 7777/udp

# 设置容器启动时执行的命令
# 假设Unity构建出的可执行文件名为 `MyGameServer.x86_64`
ENTRYPOINT ["./MyGameServer.x86_64", "-batchmode", "-nographics", "-logFile", "/dev/stdout"]

关键指令解析：

  • FROM : 指定基础镜像。我们选择官方维护的 ubuntu:22.04 ，它提供了一个干净、稳定的Linux环境。
  • RUN : 执行shell命令。我们用它来更新包列表、安装依赖。将多个 RUN 命令合并为一个，并用 && 和 \ 连接，可以减少镜像的层数，从而减小最终镜像体积。
  • USER / WORKDIR : 切换到非root用户并设置工作目录，这是安全最佳实践。
  • COPY : 将本地文件复制到镜像内。 --chown 参数确保文件所有权属于我们创建的 unityserver 用户。
  • EXPOSE : 声明容器运行时监听的端口。这只是一个文档说明，方便他人了解。
  • ENTRYPOINT : 定义容器启动时的默认执行命令。 -batchmode 和 -nographics 是Unity无头模式运行的关键参数， -logFile /dev/stdout 将日志输出到标准输出，方便使用 docker logs 查看。

实操心得 ：基础镜像的选择很重要。 ubuntu:22.04 约80MB，比 ubuntu:latest 更可控。如果你的服务器只依赖非常基础的库，可以考虑使用更小的基础镜像，如 debian:bullseye-slim 或 alpine 。但Alpine使用musl libc，可能与Unity构建的glibc环境不兼容，需要测试。稳妥起见，首次尝试建议用Ubuntu。

4. 自动化构建与部署脚本实战

有了 Dockerfile ，我们就可以开始编写核心的Shell脚本了。这个脚本将封装所有手动步骤。我们将其命名为 build_and_deploy.sh 。

4.1 脚本框架与参数定义

#!/bin/bash

# ============================================
# Unity游戏Linux服务器Docker一键构建部署脚本
# ============================================

set -e # 遇到任何命令执行失败就退出，避免错误累积

# 默认配置
PROJECT_NAME="MyUnityGame"
IMAGE_NAME="my-unity-game-server"
VERSION="latest"
TARGET_SERVER="user@your-server-ip"
SERVER_DEPLOY_PATH="/opt/game_servers"
CONTAINER_NAME="${PROJECT_NAME}_server"

# 颜色输出函数，让日志更易读
RED='\033[0;31m'
GREEN='\033[0;32m'
YELLOW='\033[1;33m'
NC='\033[0m' # No Color

log_info() {
    echo -e "${GREEN}[INFO]${NC} $1"
}
log_warn() {
    echo -e "${YELLOW}[WARN]${NC} $1"
}
log_error() {
    echo -e "${RED}[ERROR]${NC} $1"
}

# 显示用法
usage() {
    echo "用法: $0 [选项]"
    echo "选项:"
    echo "  -p, --project-name NAME    项目名称 (默认: $PROJECT_NAME)"
    echo "  -i, --image-name NAME      Docker镜像名称 (默认: $IMAGE_NAME)"
    echo "  -v, --version VERSION      版本标签 (默认: $VERSION)"
    echo "  -s, --server SERVER        目标服务器SSH地址 (默认: $TARGET_SERVER)"
    echo "  -d, --deploy-path PATH     服务器部署路径 (默认: $SERVER_DEPLOY_PATH)"
    echo "  -h, --help                 显示此帮助信息"
    exit 1
}

# 解析命令行参数
while [[ $# -gt 0 ]]; do
    case $1 in
        -p|--project-name)
            PROJECT_NAME="$2"
            shift 2
            ;;
        -i|--image-name)
            IMAGE_NAME="$2"
            shift 2
            ;;
        -v|--version)
            VERSION="$2"
            shift 2
            ;;
        -s|--server)
            TARGET_SERVER="$2"
            shift 2
            ;;
        -d|--deploy-path)
            SERVER_DEPLOY_PATH="$2"
            shift 2
            ;;
        -h|--help)
            usage
            ;;
        *)
            log_error "未知选项: $1"
            usage
            ;;
    esac
done

FULL_IMAGE_TAG="${IMAGE_NAME}:${VERSION}"

脚本开头定义了默认参数和颜色输出函数，方便区分日志级别。 set -e 确保脚本在任何一个步骤失败时立即停止，防止在错误的状态下继续执行。

4.2 步骤一：使用Unity命令行进行Linux构建

Unity编辑器支持命令行模式（ -batchmode ），这允许我们通过脚本自动触发构建。

# 步骤1: Unity命令行构建Linux服务器
log_info "步骤1: 开始使用Unity命令行构建Linux服务器..."
UNITY_PATH="/Applications/Unity/Hub/Editor/2022.3.20f1/Unity.app/Contents/MacOS/Unity" # macOS示例
# Windows示例: UNITY_PATH="C:\Program Files\Unity\Hub\Editor\2022.3.20f1\Editor\Unity.exe"
# Linux示例: UNITY_PATH="/opt/unity/Editor/Unity"

BUILD_PATH="./Builds/LinuxServer"
# 清理旧的构建输出
if [ -d "$BUILD_PATH" ]; then
    rm -rf "$BUILD_PATH"
    log_info "已清理旧构建目录: $BUILD_PATH"
fi

# 执行Unity构建命令
# -quit: 构建完成后退出Unity
# -batchmode: 批处理模式，不显示图形界面
# -nographics: 无图形模式（对于服务器构建是必须的）
# -projectPath: 指定Unity项目路径
# -executeMethod: 调用自定义的构建方法（需要在项目中编写一个Editor脚本）
# -logFile: 指定日志文件
# -buildTarget: 构建目标，Linux服务器选择StandaloneLinux64
"$UNITY_PATH" -quit -batchmode -nographics \
    -projectPath "." \
    -executeMethod BuildScript.BuildLinuxServer \
    -logFile "./unity_build.log" \
    -buildTarget StandaloneLinux64

if [ $? -eq 0 ]; then
    log_info "Unity Linux服务器构建成功！输出目录: $BUILD_PATH"
else
    log_error "Unity构建失败！请查看日志文件: ./unity_build.log"
    exit 1
fi

这里的关键是 -executeMethod BuildScript.BuildLinuxServer 。你需要在Unity项目的 Assets/Editor/ 文件夹下创建一个C#脚本，例如 BuildScript.cs ，其中包含一个静态方法 BuildLinuxServer 。

// Assets/Editor/BuildScript.cs
using UnityEditor;
using UnityEngine;
using System.IO;

public static class BuildScript
{
    public static void BuildLinuxServer()
    {
        string buildPath = Path.Combine(Directory.GetCurrentDirectory(), "Builds/LinuxServer");
        if (!Directory.Exists(buildPath))
        {
            Directory.CreateDirectory(buildPath);
        }

        // 获取构建场景
        string[] scenes = new string[] { "Assets/Scenes/ServerScene.unity" }; // 修改为你的服务器启动场景

        BuildPlayerOptions buildOptions = new BuildPlayerOptions();
        buildOptions.scenes = scenes;
        buildOptions.locationPathName = Path.Combine(buildPath, "MyGameServer.x86_64"); // 可执行文件名
        buildOptions.target = BuildTarget.StandaloneLinux64;
        buildOptions.subtarget = (int)StandaloneBuildSubtarget.Server; // 关键！指定为服务器构建
        buildOptions.options = BuildOptions.EnableHeadlessMode; // 启用无头模式

        BuildPipeline.BuildPlayer(buildOptions);
    }
}

注意事项 ： StandaloneBuildSubtarget.Server 和 BuildOptions.EnableHeadlessMode 是构建专用服务器（无图形、无音频）的关键。这能显著减少构建出的二进制文件体积，并移除不必要的运行时模块。

4.3 步骤二：构建Docker镜像

Unity构建成功后，我们使用Docker命令基于 Dockerfile 构建镜像。

# 步骤2: 构建Docker镜像
log_info "步骤2: 开始构建Docker镜像: $FULL_IMAGE_TAG"
docker build -t "$FULL_IMAGE_TAG" -f Dockerfile .

if [ $? -eq 0 ]; then
    log_info "Docker镜像构建成功: $FULL_IMAGE_TAG"
    # 可选：查看镜像信息
    docker images | grep "$IMAGE_NAME"
else
    log_error "Docker镜像构建失败！"
    exit 1
fi

docker build -t 用于给镜像打上标签。最后的 . 表示构建上下文（即 COPY 指令中源文件的相对路径）是当前目录。

4.4 步骤三：（可选）推送镜像到远程仓库

如果你有多台服务器或需要与团队共享镜像，需要将镜像推送到Docker Hub、阿里云容器镜像服务等远程仓库。

# 步骤3: 推送镜像到远程仓库（可选）
read -p "是否推送镜像到远程仓库？(y/N): " -n 1 -r
echo
if [[ $REPLY =~ ^[Yy]$ ]]; then
    log_info "步骤3: 开始推送镜像..."
    REMOTE_REGISTRY="registry.cn-hangzhou.aliyuncs.com" # 以阿里云为例
    REMOTE_IMAGE_TAG="${REMOTE_REGISTRY}/your-namespace/${FULL_IMAGE_TAG}"
    
    # 重新打标签以符合远程仓库格式
    docker tag "$FULL_IMAGE_TAG" "$REMOTE_IMAGE_TAG"
    
    # 登录远程仓库（首次需要）
    # docker login $REMOTE_REGISTRY
    docker push "$REMOTE_IMAGE_TAG"
    
    if [ $? -eq 0 ]; then
        log_info "镜像推送成功: $REMOTE_IMAGE_TAG"
        # 更新后续部署使用的镜像标签
        DEPLOY_IMAGE_TAG="$REMOTE_IMAGE_TAG"
    else
        log_error "镜像推送失败！"
        exit 1
    fi
else
    log_info "跳过镜像推送步骤。"
    DEPLOY_IMAGE_TAG="$FULL_IMAGE_TAG"
fi

4.5 步骤四：在远程服务器上部署容器

这是最后一步，通过SSH连接到目标服务器，执行Docker命令来运行容器。

# 步骤4: 在远程服务器上部署
log_info "步骤4: 开始在服务器 [$TARGET_SERVER] 上部署容器..."
# 使用SSH执行远程命令
ssh "$TARGET_SERVER" << EOF
set -e
echo "[服务器] 检查Docker服务状态..."
sudo systemctl is-active --quiet docker || { echo "Docker服务未运行！"; exit 1; }

echo "[服务器] 停止并移除旧容器（如果存在）..."
sudo docker stop $CONTAINER_NAME 2>/dev/null || true
sudo docker rm $CONTAINER_NAME 2>/dev/null || true

echo "[服务器] 拉取最新镜像（如果使用远程仓库）..."
# 如果使用了远程仓库，需要先拉取。如果是本地构建后传输，方法不同。
# 假设镜像已在本地，我们通过另一种方式：将镜像保存为文件，传输到服务器再加载。
# 这里演示直接使用本地镜像（需确保服务器能访问，或在同一台机器测试）。

echo "[服务器] 启动新的游戏服务器容器..."
# 运行容器关键参数解释：
# -d: 后台运行 (detached mode)
# --name: 指定容器名称，便于管理
# --restart=unless-stopped: 容器退出时自动重启（除非手动停止），提高服务可靠性
# -p: 端口映射，将宿主机的UDP 7777端口映射到容器的UDP 7777端口
# -v: 数据卷挂载，将服务器上的一个目录挂载到容器内，用于持久化日志或配置文件
# -e: 设置环境变量，可以传递给Unity游戏进程
# --memory=2g: 限制容器最大内存为2GB，防止内存泄漏拖垮宿主机
# --cpus=1.5: 限制容器最多使用1.5个CPU核心
sudo docker run -d \\
  --name $CONTAINER_NAME \\
  --restart=unless-stopped \\
  -p 7777:7777/udp \\
  -v ${SERVER_DEPLOY_PATH}/logs:/app/logs \\
  -e SERVER_NAME="Production_Server_01" \\
  --memory=2g \\
  --cpus="1.5" \\
  $DEPLOY_IMAGE_TAG

echo "[服务器] 容器启动命令已执行。"
echo "[服务器] 检查容器状态..."
sleep 3 # 等待容器初始化
sudo docker ps --filter "name=$CONTAINER_NAME" --format "table {{.Names}}\\t{{.Status}}\\t{{.Ports}}"
EOF

if [ $? -eq 0 ]; then
    log_info "游戏服务器已在远程服务器上成功部署并启动！"
    log_info "游戏端口: UDP 7777"
    log_info "容器名称: $CONTAINER_NAME"
    log_info "你可以使用 'ssh $TARGET_SERVER sudo docker logs -f $CONTAINER_NAME' 查看实时日志。"
else
    log_error "远程部署过程出现错误！"
    exit 1
fi

log_info "========== 一键部署流程全部完成！ =========="

远程部署命令详解：

  • --restart=unless-stopped ：这是生产环境的最佳实践。确保服务器因为程序崩溃或宿主机重启后，容器能自动重新启动，保障服务可用性。
  • -p 7777:7777/udp ：端口映射。格式为 宿主机端口:容器端口/协议 。确保宿主机防火墙也开放了该端口。
  • -v .../logs:/app/logs ：数据卷挂载。将容器内的 /app/logs 目录（假设你的游戏服务器日志写在这里）映射到宿主机的 ${SERVER_DEPLOY_PATH}/logs 目录。这样即使容器被删除，日志文件也会保留在宿主机上。
  • -e SERVER_NAME=... ：传递环境变量。你可以在Unity游戏服务器代码中使用 System.Environment.GetEnvironmentVariable("SERVER_NAME") 来读取，实现动态配置。
  • --memory 和 --cpus ：资源限制。 强烈建议设置 ，防止单个容器占用所有资源，影响宿主机或其他服务。

实操心得 ：直接通过SSH运行 docker run 适用于简单场景。对于更复杂的生产环境，建议使用 docker-compose 或容器编排工具（如Kubernetes）来定义和管理服务。 docker-compose.yml 文件可以版本化，更清晰地定义容器网络、数据卷、依赖关系等。

5. 进阶配置、优化与问题排查

掌握了基础流程后，我们来看看如何优化和应对复杂情况。

5.1 使用Docker Compose进行服务编排

对于需要多个容器（如游戏服务器+监控代理）的场景， docker-compose 是更好的选择。在服务器上创建 docker-compose.yml ：

version: '3.8'
services:
  game-server:
    image: registry.cn-hangzhou.aliyuncs.com/your-namespace/my-unity-game-server:latest
    container_name: mygame_prod
    restart: unless-stopped
    ports:
      - "7777:7777/udp"
      - "8080:8080/tcp" # 假设还有一个管理用HTTP端口
    volumes:
      - ./game_logs:/app/logs
      - ./server_config:/app/config:ro # 只读挂载配置文件
    environment:
      - SERVER_NAME=Asia_Server_01
      - MAX_PLAYERS=100
    deploy:
      resources:
        limits:
          cpus: '1.5'
          memory: 2G
    networks:
      - game-network
    # healthcheck: # 健康检查，可选
    #   test: ["CMD", "curl", "-f", "http://localhost:8080/health"]
    #   interval: 30s
    #   timeout: 10s
    #   retries: 3

  # 可以添加其他服务，比如Prometheus node-exporter用于监控
  # monitor:
  #   image: prom/node-exporter:latest
  #   ...

networks:
  game-network:
    driver: bridge

部署时，只需在服务器上运行 docker-compose up -d 。更新时，拉取新镜像后运行 docker-compose up -d --force-recreate game-server 。

5.2 镜像体积优化技巧

Unity构建的服务器文件本身可能就很大（几百MB），再加上基础镜像，很容易超过1GB。优化方法：

  1. 使用多阶段构建 ：在 Dockerfile 中，使用一个临时镜像来构建或处理文件，最后只将必要的运行时文件和最终产物复制到一个更小的运行时镜像中。 
    # 第一阶段：构建阶段（可以使用完整Ubuntu）
FROM ubuntu:22.04 as builder
# ... 安装构建工具，编译（如果需要） ...
COPY Builds/LinuxServer /tmp/build

# 第二阶段：运行时阶段（使用更小的镜像）
FROM ubuntu:22.04
RUN apt-get update && apt-get install -y --no-install-recommends libicu70 && rm -rf /var/lib/apt/lists/*
RUN useradd -m -u 1000 unityserver
USER unityserver
WORKDIR /app
# 从builder阶段仅复制必要的文件
COPY --from=builder --chown=unityserver:unityserver /tmp/build/. ./
ENTRYPOINT ["./MyGameServer.x86_64", "-batchmode", "-nographics", "-logFile", "/dev/stdout"]
  2. 清理Unity构建中的不必要文件 ：检查构建输出目录，删除调试符号文件（如 .pdb ）、开发日志等。
  3. 使用 .dockerignore 文件 ：在项目根目录创建 .dockerignore ，忽略不需要复制到镜像中的文件，如 .git/ , Library/ , Temp/ , Obj/ , Builds/ （除了LinuxServer）， .vscode/ 等。这能显著减少构建上下文大小，加速 docker build 过程。

5.3 常见问题与排查实录

即使流程再完善，实践中也难免遇到问题。这里记录几个典型问题及其排查思路。

问题1：Unity构建成功，但Docker容器启动后立即退出（Exited (1)）

  • 排查 ：使用 docker logs <container_id> 查看容器日志。最常见的原因是找不到可执行文件或依赖库。
  • 可能原因与解决 ：
    • 可执行文件权限问题 ：在 Dockerfile 的 COPY 后，添加 RUN chmod +x ./MyGameServer.x86_64 确保文件有执行权限。
    • 依赖库缺失 ：在容器内交互式检查。先构建镜像 myimg:debug ，然后运行 docker run -it --entrypoint /bin/bash myimg:debug ，进入容器后手动执行 ./MyGameServer.x86_64 ，观察报错。使用 ldd ./MyGameServer.x86_64 检查动态链接库。根据缺失的库（如 libssl.so.3 ），在 Dockerfile 的 RUN apt-get install 环节添加对应包。

问题2：客户端能连接到服务器IP，但连接超时或失败

  • 排查 ：
    1. 在服务器上运行 sudo docker ps 确认容器正在运行。
    2. 运行 sudo docker port <container_name> 确认端口映射正确。
    3. 在服务器内部测试连通性： sudo docker exec <container_name> netstat -tuln | grep 7777 查看容器内进程是否在监听正确端口。
    4. 检查宿主机防火墙： sudo ufw status 。确保允许UDP 7777端口： sudo ufw allow 7777/udp 。
    5. 如果是云服务器，还需检查云服务商的安全组规则。

问题3：容器运行一段时间后内存持续增长，最终被OOM Killer杀死

  • 排查 ： docker stats 命令可以实时查看容器的CPU、内存使用情况。
  • 解决 ：
    • 首先，确保在 docker run 时设置了 --memory 限制，这样OOM Kill只会影响容器本身。
    • 根本原因是游戏服务器可能存在内存泄漏。需要在Unity项目中进行内存分析，检查对象池是否正常工作，是否有静态引用导致对象无法被GC回收。在服务器代码中定期输出 System.GC.GetTotalMemory(false) 来监控托管内存。

问题4：如何更新正在运行的游戏服务器？

  • 蓝绿部署 ：这是推荐的生产环境更新方式。
    1. 构建新版本的镜像（如 my-game-server:v1.1 ）。
    2. 在服务器上使用新镜像启动一个新容器，映射到 不同的宿主机端口 （如 -p 7778:7777/udp ），并挂载相同的数据卷。
    3. 通过一个负载均衡器或网关，将流量从旧容器（端口7777）逐步切换到新容器（端口7778）。或者，如果你的客户端通过域名连接，只需更新DNS记录指向新容器的IP（如果IP不同）。
    4. 验证新版本运行稳定后，停止并删除旧容器。
  • 简单重启 ：对于小型服务，也可以直接 docker stop 旧容器，然后 docker run 新镜像（使用相同的容器名和端口映射， --restart 策略会使其自动重启）。但这会有短暂的服务中断。

问题5：如何收集和分析容器日志？

  • Docker原生日志 ： docker logs -f --tail 100 <container_name> 可以跟踪日志。但默认的 json-file 日志驱动可能会占用大量磁盘空间。
  • 日志驱动 ：可以在 docker run 时使用 --log-driver 指定其他驱动，如 syslog 或 journald （如果宿主机使用systemd）。
  • 挂载卷输出日志 ：最佳实践是将游戏服务器的日志文件输出到挂载卷（如 -v /host/path/logs:/app/logs ），然后使用日志收集工具（如Fluentd、Filebeat）将这些日志文件发送到集中式日志系统（如ELK Stack、Loki）进行分析。这样日志生命周期与容器解耦。

通过这套结合了Docker和Shell脚本的自动化流程，你将彻底告别手动配置Linux游戏服务器的繁琐与不确定性。从本地开发到云端部署，环境完全一致，效率大幅提升。这套方法论不仅适用于Unity，任何需要部署到Linux的服务端应用，都可以借鉴此思路。关键在于将构建、打包、部署的每一步都脚本化、容器化，最终实现稳定、可靠、可重复的一键部署。

Logo
亚马逊云科技技术品牌专区

更多推荐

cover

【Flink SQL 学习笔记 二】实时聚合：用窗口和 Watermark 把订单按时段统计

avatar 亚马逊云科技技术品牌专区

2026 大模型量化：怎么把 70B 大模型塞进 24G 显存？（MonkeyCode 云端实战）

2026年开源大模型参数动辄几百亿，模型文件动辄上百GB，能不能跑起来比的不是代码写得多漂亮，而是谁更会"压缩"。本文讲透大模型量化：量化到底在压什么？核心公式、PTQ与QAT两条路线、INT8/INT4位宽与精度权衡、混合精度的聪明做法，以及量化如何让端侧离线环境都能跑大模型。用MonkeyCode云端沙箱跑真实量化流程，让AI自己写代码加载模型、做量化、实测显存与速度对比，内置多款主流大模型一

avatar 亚马逊云科技技术品牌专区

AutoDL部署大模型dots.ocr

大模型部署

avatar 亚马逊云科技技术品牌专区