Skip to main content
Прежде чем нырять с головой, вам стоит как минимум пройти через хостинг обычного сервера и научиться им управлять.Также может быть полезно ознакомиться с настройкой среды разработчика, так как вам понадобится хотя бы dotnet для компиляции Watchdog и Python для запуска некоторых скриптов сборки сервера.Также стоит ознакомиться с разделом о пользовательских кодовых базах, особенно если вы собираетесь использовать их с кастомной кодовой базой.
SS14.Watchdog (кодовое имя Ian) — это наша обёртка для хостинга серверов, похожая на TGS для BYOND (но на данный момент гораздо проще). Он обрабатывает автообновления, мониторинг, автоматические перезапуски и администрирование. Мы рекомендуем использовать его для полноценных развёртываний.

Процесс настройки

1. Проверка предварительных требований

Вам необходимо иметь:
  • .NET 10 SDK
  • ASP .NET Core 10 Runtime
Всё это можно найти на странице загрузки .NET 10. В Linux используйте ваш любимый пакетный менеджер (apt, dnf, pacman, brew и т.д.) в соответствии с инструкциями Microsoft.

2. Сборка

Следующий набор команд должен собрать Watchdog в Linux-системе. Вам, конечно, придётся адаптировать его под вашу реальную систему.
Содержимое SS14.Watchdog/bin/Release/net10.0/linux-x64/publish затем можно скопировать в другое место. Здесь вы продолжите работу.

3. Запуск

Предполагая, что вы следовали описанной выше структуре, вам просто нужно открыть терминал в папке, куда вы скопировали файлы, и запустить исполняемый файл SS14.Watchdog.

Конфигурация Watchdog

Конфигурационный файл Watchdog — appsettings.yml Конфигурация watchdog разделена на два основных раздела:
  • Глобальные элементы, общие для всех экземпляров (серверов).
  • Элементы для каждого экземпляра.

Serilog, AllowedHosts

Обычно их не нужно менять, и они слишком сложны для описания здесь.

BaseUrl

Представляет внешний URL Watchdog. Он автоматически передаётся экземплярам, чтобы они могли связываться с Watchdog. Также используется в режимах обновления, требующих подключения клиентов к Watchdog для получения ресурсов.

Urls

Контролирует, на каких интерфейсах работает Watchdog, что может быть важно в некоторых случаях. В частности, это может использоваться для открытия доступа к Watchdog извне localhost без обратного прокси, например:
Смотрите соответствующую документацию для более подробной информации: docs.microsoft.com Не забудьте соответствующим образом изменить BaseUrl!

Уведомления

Теперь вы можете настроить Discord webhook для уведомлений, чтобы получать сообщения при сбое сервера; интеграция настолько же проста, как добавление следующего в вашу конфигурацию.

Экземпляры (Instances)

Каждый экземпляр — это отдельный игровой сервер, поэтому термины «экземпляр» и «сервер» можно использовать как взаимозаменяемые.

Папка экземпляра сервера

Watchdog автоматически создаст структуру папок для каждого экземпляра сервера. Она находится в instances/<instanceId>, например instances/wizards_den / instances/wizards_den_two, относительно текущей рабочей директории при выполнении watchdog. В примере конфигурации выше это было бы instances/example Каждая папка экземпляра содержит следующие файлы и папки:
  • binaries/: Используется для хранения клиентских бинарных файлов при использовании типа обновления «Local», см. ниже.
  • bin/: Содержит собственно извлечённые серверные бинарные файлы.
  • data/: Хранит данные сервера, такие как предпочтения игроков.
  • config.toml: Это конфигурационный файл, который будет загружать сервер (watchdog переопределяет расположение по умолчанию, server_config.toml рядом с .exe, чтобы он не удалялся при сбросе сервера). Возможно, вам придётся создать этот файл вручную в первый раз.
  • data.json: Содержит информацию watchdog. Если вы изменили тип обновления и получаете ошибки, удалите этот файл.
Обратите внимание, что хотя watchdog обрабатывает обновления сервера, вам всё равно может потребоваться настроить config.toml в соответствии с руководством оператора сервера.

Управление Watchdog

Есть две ключевые ситуации, когда требуется управление watchdog. Во-первых, watchdog будет обновляться только тогда, когда ему либо явно сообщат проверить наличие обновлений, либо когда он будет перезапущен. Во-вторых, вы можете просто принудительно перезапустить сервер. В-третьих, вы можете захотеть завершить сервер после окончания раунда. Например, для обслуживания. Эти задачи можно выполнить с помощью следующих команд: curl -v -X POST -u myInstance:ApiToken http://localhost:5000/instances/myInstance/restart curl -v -X POST -u myInstance:ApiToken http://localhost:5000/instances/myInstance/update curl -v -X POST -u myInstance:ApiToken http://localhost:5000/instances/myInstance/stop

Типы обновлений

Манифестное обновление (Manifest)

Сервер всё равно не будет автоматически уведомлён об обновлениях, поэтому смотрите инструкции выше.
Тип Manifest — это метод, который используют все серверы Wizard’s Den, и мы рекомендуем его. Manifest требуется для возможности записи реплеев.

Git-обновления

Метод обновления на основе Git не поддерживается. Хотя это самый простой способ начать работу, мы не сможем вам помочь, если он сломается. Вы в основном предоставлены сами себе.
Использование Git-обновлений предполагаемым образом может находиться в различных состояниях «сломанности» из-за различных способов, которыми репозиторий может прийти в состояние, которое лучше всего описать как, ну, сломанное. Это не должно касаться вас, если вы просто доставляете предварительно скомпилированные обновления на сервер с помощью Git, но это тоже неудобно и не является предполагаемым способом работы.
SS14.Watchdog может компилировать и обновлять сервер, когда коммиты отправляются в ветку Git-репозитория, содержащего исходный код вашего форка.
Для этого на сервере должны быть необходимые части среды разработчика. Кроме того, вам всё равно нужно написать Git hook или что-то подобное, чтобы гарантировать, что Watchdog уведомляется об обновлениях, или иным образом заставить его периодически проверять наличие обновлений.

Jenkins-обновления

Это древний метод, но он всё ещё должен работать.

Провайдер обновлений «Dummy»

Провайдер обновлений «Dummy» будет имитировать обновление при каждом запросе, а в остальном просто предполагает, что сервер уже извлечён в bin/. Поскольку Watchdog не проверяет автоматически наличие обновлений периодически, имитация обновлений не должна мешать. Чтобы настроить это, используйте следующую конфигурацию обновления в вашем appsettings.yml в записи для вашего экземпляра сервера:

Пользовательские автообновления

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

Типы обновлений (сделай сам)

Провайдер обновлений «Dummy», версия DIY

Прежде чем пытаться это сделать, убедитесь, что вы знакомы с использованием провайдера обновлений «Dummy» в целом. Настроить всё для поддержки обновлений относительно просто. Следующие инструкции предназначены для Unix-подобных систем, но идея должна быть понятна в любом случае. Начните с настройки следующим образом:
Основная идея этого механизма — использование символических ссылок для переключения между используемыми директориями. Для этого нужны три скрипта: switchTo, switchTo1 и switchTo2: switchTo:
switchTo1:
switchTo2:
После того как эти скрипты сделаны исполняемыми (chmod +x switchTo*) и один из них запущен, выполнение ./switch после этого будет переключать между двумя директориями. Таким образом, рабочий процесс заключается в удалении всего из inactiveBin, затем извлечении нового сервера туда, а затем запуске ./switch для подтверждения. Перед очисткой и извлечением новой сборки сервера в inactiveBin убедитесь, что сервер действительно перезапустился после предыдущего обновления и больше не использует эту директорию.

DIY-манифест сервера

Это быстрый скрипт, полезный для настройки DIY-сервера для типа обновления Manifest, описанного в разделе о манифесте. Он предполагает, что у вас есть произвольный статический HTTP-сервер, и вам нужен только скрипт для вывода JSON с обновлённой датой (чтобы вы могли просто передать два файла на статический HTTP-сервер и инициировать обновление).

Systemd-сервис

Чтобы watchdog работал в фоне и автоматически запускался при загрузке сервера, вы можете создать сервисный файл. Он будет выглядеть примерно так. Разумеется, настройте его под актуальную директорию вашего watchdog. Если ваш дистрибутив не использует systemd в качестве инита, вам придётся преобразовать это в соответствующий init.
Из-за того, как работают сервисы, вы не сможете использовать консоль сервера SS14 напрямую из терминала, если это необходимо. Убедитесь, что вы предоставили себе разрешения на сервере, чтобы использовать команды sudo или > для выполнения команд на сервере.
/etc/systemd/system/SS14.Watchdog.service
Теперь перезагрузите демон systemd и включите сервис обычным образом.
Если вы ещё не знаете, как использовать systemctl, сейчас самое время узнать. Для просмотра логов используйте journalctl.

Персистентность серверов

Изменение конфигурации watchdog или его обновление требует перезапуска, и по умолчанию это означает перезапуск всех игровых серверов, работающих под watchdog. Начиная с коммита 6194ed4, watchdog поддерживает персистентность серверов. Это позволяет перезапускать его независимо, не затрагивая сами игровые серверы. Чтобы настроить это, добавьте следующее в ваш appsettings.yml:
С этой настройкой watchdog не будет завершать игровые серверы при собственном завершении и при перезапуске попытается найти предыдущий процесс игрового сервера, чтобы продолжить наблюдение за ним.

Systemd

При размещении watchdog в качестве сервиса Systemd вышеописанного недостаточно. С настройками Systemd по умолчанию перезапуск watchdog приведёт к тому, что Systemd также убьёт процессы игровых серверов. Этого можно избежать, установив следующее в определении сервиса:
Это заставит Systemd останавливать только основной процесс watchdog, не затрагивая процессы игровых серверов ниже. Это, конечно, означает, что попытка выполнить systemctl stop ss14-watchdog не остановит игровые серверы, даже если они неправильно работают/зависли.

Общие неполадки

Сервер постоянно перезапускается каждые 30 секунд

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

System.IO.FileNotFoundException: Could not load file or assembly 'Mono.Posix.NETStandard, Version=1.0.0.0, Culture=neutral (…)

Текущая рабочая теория состоит в том, что это вызвано неправильными параметрами dotnet publish. Приведённый ниже набор результатов тестов должен помочь объяснить.
Поскольку Watchdog использует Mono.Posix.NETStandard.dll для пометки исполняемых файлов как исполняемых в Linux и Mac OS X, важно иметь его в этих ОС.

Пример старой конфигурации

(Этот раздел извлечён из более старой версии данного руководства с небольшими изменениями на случай, если он всё ещё может быть полезен. Возможно, он устарел.) Пример с наших официальных серверов (токены, очевидно, удалены):
Последнее изменение 21 июня 2026 г.