RE:NODE

Эксплуатация10 мин чтения

Тестовый игровой сервер рядом с основным

Как держать второй игровой сервер для проверки обновлений, модов и конфигов: что копировать, что обязательно должно отличаться, как сэкономить и как безопасно переносить изменения.

0 прочтений

Тестовый сервер - это вторая, меньшая копия вашего игрового сервера: та же версия игры, те же моды, свежая копия мира, - но с другим именем, собственными паролями и токенами и без возможности для игроков случайно на него попасть. Каждое обновление игры, обновление модов и рискованное изменение конфига сначала идёт туда; и только когда сервер запускается, загружает мир и переживает час ваших экспериментов, то же изменение идёт на настоящий сервер. Для модового сервера это разница между тем, чтобы найти сломанный мод за рабочим столом во вторник днём, и тем, чтобы найти его в пятницу вечером, когда сорок человек в Discord спрашивают, что случилось. Это стоит одного дополнительного небольшого тарифа, и большую часть месяца он может стоять выключенным.

Эта статья - игровая версия этой идеи. Общие принципы staging-окружений, написанные в основном для веб-приложений, - в статье staging и production в одном аккаунте. Здесь заботы специфичны для игр: копии мира, совпадение модов на клиентах, токены, которыми одновременно может пользоваться только один сервер, и общие базы данных, через которые тестовый сервер тихо меняет настоящий.

Что тестовый сервер ловит, а что нет#

Чётко понимайте, что вы покупаете: тестовый сервер отлично справляется с одними вещами и бесполезен для других.

Он надёжно ловит:

  • Моды, которые ломаются при обновлении игры. Самая частая причина падения модового сервера и самая простая для поимки: обновите тестовый сервер, запустите, прочитайте лог.
  • Проблемы с конвертацией мира. Крупные обновления игры конвертируют сохранение при первой загрузке. Если сначала сделать это с копией, вы узнаете, работает ли это и сколько занимает времени.
  • Ошибки в конфигах. Опечатка в YAML-файле, пропущенная скобка в INI, настройка, которая делает не то, что подразумевала документация.
  • Конфликты плагинов и модов. Два плагина, которые дерутся за одно событие или команду, проявляются сразу, как только оба загрузятся.
  • Процедуры. Сколько на самом деле занимает обновление, какие файлы нужно копировать, в каком порядке всё делать. Вы узнаёте это, когда никто не смотрит.

Он не ловит:

  • Проблемы под нагрузкой. Два тестировщика не воспроизведут сорок игроков. Изменение, которое лагает только под нагрузкой, пройдёт все тесты.
  • Тайминг и случайность. Краши, для которых нужно определённое сочетание событий - рейд во время сохранения во время рестарта, - на тихом сервере редки.
  • Поведение игроков. Эксплойт, который кто-то найдёт в первый же час работы нового мода.

Тестовый сервер уменьшает число сюрпризов, но не убирает их. В любом случае делайте backup перед каждым изменением на основном сервере, как описано в статье стратегия резервного копирования игрового сервера.

Размер и стоимость#

Тестовому серверу не нужно соответствовать основному. Ему нужно достаточно памяти, чтобы загрузить тот же мир и моды, и совсем немного CPU, потому что на нём никто не играет.

Основной серверРазумный тестовый серверПочему
Ванильный, маленький мирЧасто не нуженВанильные обновления редко ломают то, что вы можете починить
Немного модов, 2-4 GBСамый маленький тариф, на который помещаются модыПроверяются запуск и загрузка
Тяжёлый модпак, 8-12 GBТа же память, меньше ядерМодпакам память нужна просто чтобы запуститься
С модами и большим миромТа же память или тест на урезанном миреРазмер мира определяет время загрузки и память

На RE:NODE самые маленькие игровые тарифы начинаются от $3 в месяц для самых лёгких игр и стоят больше для тяжёлых (актуальные цены - на странице каждой игры в разделе игровые серверы), у каждого тарифа одна и та же панель, и ничего не закрыто по уровню тарифа, так что у маленького тестового сервера те же консоль, файлы, расписания и backup, что и у большого. Сервер, который вы запускаете только для тестов, всё равно стоит свою месячную цену - почасовой оплаты нет, - так что экономия достигается выбором маленького тарифа, а не тем, что сервер выключен.

Альтернатива для лёгкого изменения - обойтись без второго сервера: сделать заблокированный backup, попробовать изменение на основном сервере в тихий час и восстановиться, если не получилось. Для небольшой группы это законный подход. Он перестаёт быть таковым, когда сервер загружен, когда изменение затрагивает десятки модов или когда откат неудачного обновления занимает больше нескольких минут.

Настройка: скопируйте основной сервер, затем осознанно измените копию#

Самый быстрый способ сделать точную копию - из backup настоящего сервера:

  1. Сделайте backup основного сервера, лучше после команды сохранения, чтобы мир был целостным.
  2. Скачайте его из панели.
  3. На новом сервере загрузите архив через файловый менеджер и распакуйте его на месте или загрузите папки по SFTP. Оба способа описаны в статье SFTP и файловый менеджер.
  4. Выставьте переменные запуска как на основном сервере: версия игры или ветка, флаги памяти, параметры списка модов.
  5. Перед первым запуском внесите изменения из следующего раздела. Тестовый сервер, запущенный с идентичностью основного, может объявить себя в публичном списке серверов, перехватить токен основного или писать в его базу данных.

Затем запустите его, убедитесь, что он загрузил скопированный мир (в логе указано имя загруженного мира), и снова остановите.

Что обязательно должно отличаться#

Это самое важное, потому что небрежная копия наносит реальный ущерб.

НастройкаПочему должна отличаться
Имя сервераЧтобы никто не зашёл на него по ошибке из списка серверов
Пароль сервера или входаЧтобы попадали только тестировщики
Отображение в спискахСкрыт из публичных списков везде, где игра это позволяет
Пароли админа, RCON и веб-панелиУтёкший тестовый пароль не должен открывать основной сервер
Токен игрового сервера SteamОдним токеном может пользоваться только один работающий сервер
База данных или префикс базыЧтобы плагины тестового сервера не писали в данные основного
Токены Discord-ботов и вебхукиЧтобы тестовые события не публиковались в общих каналах
Секреты форвардинга проксиЧтобы тестовый бэкенд не был доступен через живой прокси
Задачи по расписаниюЧтобы тестовый сервер не перезапускался и не рассылал оповещения по расписанию основного

Некоторые пункты требуют подробностей.

Отображение в списках. У Valheim есть -public 0; игры на Source принимают sv_password; Minecraft может не попадать в списки серверов, если его не рекламировать и выставить enable-status=false в server.properties - тогда он не отвечает на пинги списков; большинство игр Steam скрываются из браузера серверов, если у них задан пароль или они помечены как приватные в собственном конфиге. Пароль - минимум везде.

Токены Steam. Counter-Strike 2, Garry's Mod, Team Fortress 2 и другие используют токен входа игрового сервера (GSLT). Токен может использоваться одним сервером одновременно, поэтому тестовый сервер, запущенный с токеном основного, может выбить настоящий сервер из сети или сам не зарегистрироваться. Создайте для тестового сервера второй токен; как это сделать, описано в статье токены игрового сервера Steam.

Базы данных. Это самое опасное. Плагины Minecraft вроде LuckPerms, CoreProtect и плагинов экономики можно настроить на общую базу данных; фреймворки FiveM хранят всё в одной базе через oxmysql; DarkRP в Garry's Mod может использовать внешнюю базу. Тестовый сервер, скопированный с теми же настройками подключения, подключён к настоящим данным. Повысьте тестового игрока до админа - и вы повысили его на основном сервере. Дайте тестовому серверу собственную базу данных - на RE:NODE в каждый игровой тариф входит слот базы данных, который создаётся в панели со своим хостом, пользователем и паролем, - и восстановите в неё копию данных основного сервера. Дамп и восстановление описаны в статье backup и восстановление баз данных.

Discord. Скопированный конфиг DiscordSRV или URL вебхука будет публиковать чат, смерти и консоль тестового сервера в настоящих каналах вашего сообщества. Направьте его в закрытый тестовый канал или отключите.

Как держать клиентов в соответствии#

Тестовый сервер для игры, где моды нужны и клиентам, - большинство модпаков Minecraft, Valheim с геймплейными модами, мультиплеер RimWorld, - полезен, только если у тестировщиков есть клиент с точно тем же набором модов, что на тестовом сервере. Значит, на машине тестировщика нужны два профиля клиента:

  • Minecraft: отдельные инстансы в Prism Launcher, приложении CurseForge или приложении Modrinth, по одному на сервер.
  • Valheim: отдельные профили в менеджере модов вроде r2modman или Gale.
  • Игры со Steam Workshop: сложнее, потому что подписки Workshop привязаны к аккаунту. Тестирование обновления мода из Workshop обычно означает тестирование с обновлёнными модами и согласие с тем, что основной сервер вскоре последует за ними.

Без отдельных профилей тестировщик, обновивший клиент для тестового сервера, не может зайти на основной, пока тот тоже не обновится, - а это ровно та связка, которой вы пытались избежать.

Порядок действий в день обновления#

Когда тестовый сервер есть, обновление игры или мода выглядит так:

  1. Обновите тестовый сервер с основного, если копии больше недели. Тест на мире прошлого месяца пропускает проблемы этого месяца.
  2. Примените обновление только к тестовому серверу: обновление игры, затем подходящие к нему обновления модов. Для игр Steam это значит запустить обновление на тестовом сервере, пока основной остаётся на старой сборке, или переключить тестовый сервер на бета-ветку разработчика до релиза, если она есть. -beta описан в статье SteamCMD простыми словами.
  3. Запустите его и прочитайте лог сверху донизу: каждый мод загрузился, исключений нет, мир загружен под своим настоящим именем.
  4. Зайдите и проверьте то, что изменилось: обновлённый мод, область, которая скорее всего сломается, сохранение и рестарт.
  5. Запишите точно, что вы изменили: имена файлов, версии, ключи конфигов. Этот список вы примените к основному серверу.
  6. Сделайте заблокированный backup основного сервера.
  7. Примените список к основному серверу в тихий час, запустите его и прочитайте лог так же.

День обновления целиком - патчноуты, авторы модов, объявления - описан в статье чек-лист дня обновления игрового сервера.

Как не дать серверам разойтись#

Тестовый сервер полезен, только пока соответствует основному. Расходятся они предсказуемо: кто-то во время аварии правит основной сервер напрямую, кто-то пробует мод на тестовом и не удаляет его, игра обновляется на одном и не обновляется на другом.

Это предотвращают три привычки:

  • Один список изменений. Каждое изменение попадает в единый датированный журнал - текстовый файл в корне сервера, закреплённое сообщение в Discord, git-репозиторий конфигов. Если изменения нет в списке, его не было.
  • Пересоздавайте, а не чините. Если тестовый сервер разошёлся с основным, не исправляйте его файл за файлом. Скачайте свежий backup основного сервера, пересоберите из него тестовый, затем заново примените изменения идентичности из таблицы выше.
  • Держите манифест версий. Файл, где перечислены сборка игры, версия загрузчика модов и версия каждого мода, - на обоих серверах. Сравнить два манифеста - минута; сравнить две папки модов на глаз - час.
versions.txt
game        Valheim <build> (public branch)loader      BepInExPack_Valheim <version>mods        Jotunn <version>            PlantEverything <version>updated     2026-10-04 by Mira - PlantEverything <old> -> <new>

Подставьте настоящие номера сборки и версий из лога запуска и со страницы каждого мода.

Кому давать доступ к тестовому серверу#

Тестовый сервер - правильное место, чтобы щедро раздавать доступ. Разработчику, которому никогда не дали бы доступ к файлам основного сервера, можно дать полный доступ к тестовому - файлы, SFTP, консоль, расписания, - потому что худший исход - пересобрать его из backup. На RE:NODE это отдельная выдача доступа на отдельный сервер: дайте команде полные права на тестовом сервере и только консоль - или ничего - на основном. Как проектировать роли, описано в статье субпользователи и минимальные права.

Единственное, чего у тестового сервера не должно быть никогда, - это секретов основного. Если человек с доступом к тестовому серверу может прочитать конфиг с паролем RCON основного сервера, паролем его базы данных или токеном живого Discord-бота, разделение чисто декоративное.

FAQ#

Действительно ли нужен тестовый сервер для небольшой группы?

Для ванильного сервера или пары серверных плагинов - обычно нет. Достаточно заблокированного backup перед каждым изменением и тихого часа, чтобы его опробовать. Тестовый сервер окупается, когда список модов длинный, мир ценен или от работы сервера зависит больше горстки людей.

Может ли тестовый сервер использовать тот же токен Steam, что и основной?

Нет. Токен входа игрового сервера может использоваться одним сервером одновременно, так что два сервера будут выбивать друг друга из сети. Создайте для тестового сервера второй токен.

Можно ли запустить тестовый сервер на том же тарифе, что и основной?

Не в игровой панели, где каждый тариф - это один сервер со своими лимитами. На VDS можно запустить оба - в двух папках, на двух портах и в идеале от двух пользователей, - ценой того, что они делят память и CPU машины.

Как часто обновлять тестовую копию?

Перед каждым значимым тестом, если копии больше одной-двух недель. Тест на устаревшем мире пропускает проблемы во всём, что игроки построили с тех пор.

Стоит ли копировать проверенный мир обратно на основной сервер?

Нет. Копируйте изменённые файлы - моды, конфиги - и не трогайте мир основного сервера. Тестовый мир старее и содержит ваши тестовые правки; копирование его обратно откатит игроков.


Комментарии

Полностью анонимно: без аккаунта, без почты, без cookie. Мы храним имя, которое вы ввели, текст и время - больше ничего. Количество ссылок ограничено, разметка не отображается.

0/2000