Обзор
Стандартный рабочий процесс публикации для Space Station 14 выглядит так:- Сборки периодически создаются системой CI, такой как GitHub Actions.
- Файлы сборок (клиентские и серверные zip-архивы) отправляются на центральный сервер. Серверные сборки индексируются, в них внедряется конфигурация для клиентского CDN, клиентские файлы обрабатываются, чтобы лаунчер мог их скачать.
- Игровые серверы (через SS14.Watchdog) получают уведомление об обновлении и автоматически загружают новые серверные сборки с центрального сервера.
- Внедрённая конфигурация игрового сервера используется для информирования клиентов о том, где они могут скачать файлы.
- Получение новых сборок напрямую от GitHub Actions.
- Предоставление серверных сборок для доступа игровым серверам (watchdog).
- Автоматическое уведомление watchdog’ов о новом обновлении.
- Предоставление дельта-загрузок для клиентов.
Концепции
Robust.Cdn в настоящее время выполняет две основные функции:- Управление манифестами серверов
- Управление дельта-загрузками клиентов
Запускать Robust.Cdn можно и без использования поддержки манифеста сервера. Фактически, до версии 2.0 Robust.Cdn занимался только клиентским CDN. См. остальную документацию для подробностей.
Установка
Мы предоставляем официальные образы контейнеров Robust.Cdn через GitHub Container Registry. Кроме того, у нас есть инструкции по самостоятельной публикации проекта с помощью .NET SDK.Образ контейнера
Последний стабильный образ Robust.Cdn —ghcr.io/space-wizards-federation/robust.cdn:2. Информация о контейнере:
- Слушает на порту 8080
- UID/GID по умолчанию — 1654
- Важные тома для монтирования:
/app/appsettings.json: основной конфигурационный файл./builds: содержит zip-файлы серверных/клиентских сборок./manifest: содержит базу данных SQLite для операций с манифестом сервера./database: содержит базу данных SQLite для загрузок клиентского контента.
docker-compose.yml, пожалуйста, измените его под свои нужды.
builds, manifest и database. Если вы получите ошибку «unable to open database file», попробуйте команды ниже.
Ручная компиляция
Если вы ненавидите контейнеры, вы можете вручную опубликовать Robust.Cdn и развернуть файлы самостоятельно. Для этого вам понадобятся Git и .NET 10 SDK. Серверу, который будет запускать сборку, требуется соответствующая среда выполнения ASP.NET Core Runtime, но SDK ему не нужен. Клонируйте git-репозиторий, затем опубликуйте:Robust.Cdn/bin/Release/net9.0/linux-x64/publish. Вы можете скопировать её в любое удобное место, например в /opt, и запускать Robust.Cdn оттуда. Например:
Конфигурация
Robust.Cdn — это ASP.NET Core-приложение, поэтому оно поддерживает настройку как через конфигурационный файл, так и через другие источники, например переменные окружения. Вы можете обратиться к документации ASP.NET Core для более подробного обзора. Большая часть конфигурации Robust.Cdn осуществляется через конфигурационный файлappsettings.json. Вот полная справка по его содержимому:
Вам следует полностью изучить этот конфигурационный файл, чтобы понять, что вы настраиваете.
Примеры конфигураций обратного прокси
Robust.Cdn — это HTTP-сервис, поэтому вы, вероятно, захотите запускать его за каким-либо обратным прокси. Есть несколько вещей, которые нужно проверить:- При использовании multi-request публикации установите максимальный размер тела клиента, чтобы он вмещал всю клиентскую загрузку целиком.
- При использовании одноэтапной публикации установите достаточно большой тайм-аут запроса (обычно более минуты-двух).
Не размещайте его за Cloudflare
Nginx
Этот пример предназначен для размещения в существующем блокеserver вашей конфигурации (терминация TLS, имя сервера и т.д.)
Caddy
Это пример Caddyfile для размещения в существующем блоке для домена с CDN. Если вы помещаете это в подпуть, вы можете просто поместить всё это в этот подпуть.Настройка публикации
GitHub Actions
Если репозиторий вашего форка размещён на GitHub, самый простой способ автоматически публиковать новые сборки в Robust.Cdn — это использовать конфигурацию GitHub Actions, доступную в кодовой базе. Именно так публикуются официальные сборки Wizard’s Den.- Отредактируйте
Tools/publish_multi_request.py, чтобы изменить «параметры конфигурации» в верхней части скрипта:
ROBUST_CDN_URLдолжен быть URL, по которому доступен Robust.Cdn.FORK_IDдолжен быть ID форка, который вы настроили вappsettings.json
-
Создайте секрет Actions в вашем GitHub-репозитории с именем
PUBLISH_TOKEN, содержащийUpdateToken, указанный для вашего форка вappsettings.json. - Убедитесь, что рабочий процесс «Publish» запущен, или запустите его вручную.
Собственная публикация
Для тех, кто хочет использовать собственные рабочие процессы публикации без GitHub Actions, вы также можете использовать скриптTools/publish_multi_request.py. Я рекомендую посмотреть на Actions workflow как на справочный материал для требуемых шагов.
Конфигурация Watchdog
Настройка SS14.Watchdog для использования вашего нового Robust.Cdn для получения сборок довольно проста. В конфигурации экземпляра укажите примерно следующее:NotifyWatchdogs в конфигурации форка Robust.Cdn, чтобы он уведомлял SS14.Watchdog о появлении новой версии. Смотрите справочную информацию выше.
HTML-страница сборок
Robust.Cdn генерирует простую HTML-веб-страницу, позволяющую людям вручную скачать последние серверные сборки. Эта страница доступна автоматически по адресу/fork/<fork_id>.
Например: Wizard’s Den builds.
Пользовательский PathBase
Если по какой-то причине у вас не может быть поддоменов (серьёзно, используйте поддомены, если можете), вы можете захотеть разместить несколько сервисов за одним доменом с помощью обратного прокси, такого как nginx. Когда вы это делаете, вам нужно установитьPathBase в конфигурационном файле, чтобы ссылки на HTML-странице сборок работали. На другие функции API это не влияет.
Например, если вы хотите разместить CDN по адресу https://example.com/cdn/, настройте это так:
Приватные форки
Форк может быть помечен как «приватный». Это не позволяет Robust.Cdn предоставлять неавторизованным лицам доступ к серверным сборкам, что желательно для форков с секретным контентом. Доступ ограничен с помощью HTTP Basic authentication. Имена пользователей и пароли для этого можно настроить в конфигурации форка. Чтобы предоставить watchdog’у доступ к этим сборкам, вы можете настроить его в конфигурации обновления экземпляра следующим образом:Структура файлов сборок
Robust.Cdn хранит и ожидает zip-архивы сборок в директорииFileDiskPath (/build при использовании образа контейнера). Файлы в этой директории имеют довольно простую структуру <fork>/<version>/<file>.zip. Например:
Устранение неполадок
504 gateway timeout во время публикации
Увеличьте тайм-аут ответа вашего обратного прокси. В nginx это контролируется черезproxy_read_timeout.
Ошибки подключения во время публикации (multi-request publish)
Убедитесь, что максимальный размер тела вашего обратного прокси установлен достаточно высоким.Ошибка 404 not found на CDN API во время публикации
Убедитесь, что вы используете последнюю версию Robust.Cdn. Версия 2.2.0 добавила новый механизм публикации, который используется основной инфраструктурой.Миграция с Robust.Cdn 1.x
Если у вас была существующая установка Robust.Cdn до добавления поддержки множественных форков/манифеста сервера (1.0), эта часть руководства поможет вам с миграцией. В рамках поддержки множественных форков и манифеста необходимо внести следующие изменения в вашу настройку, как минимум:Cdn.UpdateTokenв конфигурации перемещён в конфигурацию форка.Cdn.VersionDiskPathфактически изменён наManifest.FileDiskPath. Обратите внимание, что структура файлов отличается, вам нужно будет вручную переместить сборки на одну папку вниз, чтобы они оказались внутри папки форка (см. выше).
Cdn.DefaultFork в конфигурации, чтобы система знала, к какому форку привязать эти версии. Существующие URL (для реплеев и т.д.) продолжат работать после этого, так как настройка Cdn.DefaultFork заставит CDN внутренне перенаправлять старые URL /version/{version}/* на новые в указанном форке.
После внесения вышеуказанных изменений более новый Robust.Cdn всё ещё может использоваться со старым рабочим процессом публикации (с использованием gen_build_info.py и всех других скриптов). Просто не забудьте учесть изменения в структуре файлов и прочее. Очевидно, мы рекомендуем как можно скорее перейти на новую встроенную систему публикации.
Импорт существующего содержимого манифеста сервера
Вы можете вручную импортировать ваш существующий манифест сервера в базу данных манифеста с помощью следующего Python-скрипта. Обратите внимание, что это действительно необходимо только в том случае, если вы хотите иметь возможность легко получать доступ к старым версиям сервера через HTML-страницу или что-то подобное; пропуск этого шага… Это очень коряво, и вам нужно будет опубликовать хотя бы одну сборку обычным способом, чтобы JSON-манифест сервера был перекэширован и стал доступен. Но, эй, это работает. Если скрипт не работает из-за отсутствияdateutil, в Python 3.10+ вы можете удалить код, использующий dateutil, заменив dateparser.parse на datetime.fromisoformat.
Справочник по API Robust.Cdn
Эта часть руководства объяснит все эндпоинты API Robust.Cdn, которые вы можете использовать.Аутентификация
Некоторые эндпоинты API могут требовать аутентификации:- Эндпоинты управления форком, такие как публикация, требуют
Authorization: Bearer <updateToken>, гдеUpdateTokenуказан в конфигурации форка. - Эндпоинты для доступа к серверным файлам требуют базовой аутентификации, если форк настроен как приватный.
Публикация
Существует два отдельных API для публикации: «одноэтапный» (one-shot) и «многозапросный» (multi-request). Одноэтапный API находится по адресу/fork/{fork}/publish, в то время как многозапросный — по адресу /fork/{fork}/publish/{start,file,finish}. Мы рекомендуем многозапросный API публикации, и именно его используют официальные скрипты публикации.
GET /fork/{fork}
Возвращает удобную для чтения HTML-страницу о последних доступных сборках.
POST /fork/{fork}/control/update
Даёт команду клиентскому CDN пересканировать новые файлы. Вы можете запустить это вручную, если не используете поддержку манифеста сервера Robust.Cdn, а используете только клиентский CDN. Вам нужно поместить файлы в правильную структуру, указанную ниже.
Требует аутентификации.
GET /fork/{fork}/manifest
Возвращает JSON-список всех доступных серверных сборок для форка.
POST /fork/{fork}/publish
Публикует новую версию в CDN за один API-запрос. Это в отличие от «многозапросного» API, описанного ниже.
Ожидает тело JSON со следующей информацией:
POST /fork/{fork}/publish/start
Начинает новую операцию публикации, включающую несколько последующих API-запросов. Начальное тело JSON-запроса выглядит так:
POST /fork/{fork}/publish/file
Добавляет дополнительный файл к выполняемой публикации.
Содержимое файла передаётся в теле запроса как application/octet-stream. Дополнительные метаданные должны быть переданы в следующих HTTP-заголовках:
Robust-Cdn-Publish-File: имя публикуемого файла. Обычно это что-то вродеSS14.Client.zipилиSS14.Server_win-x64.zip.Robust-Cdn-Publish-Version: номер версии, в которую происходит публикация (указан ранее).
POST /fork/{fork}/publish/finish
Завершает публикацию новой версии, начатую ранее.
POST & OPTIONS /fork/{fork}/version/{version}/download
Эндпоинт загрузки клиентского CDN для версии. См. Delta Updates для подробностей.
GET /fork/{fork}/version/{version}/file/{file}
Загружает zip-архив серверной или клиентской сборки из версии. File — имя файла.
GET /fork/{fork}/version/{version}/manifest
Эндпоинт манифеста клиентского CDN для версии. См. Delta Updates для подробностей.
POST & OPTIONS /version/{version}/download
Запасной эндпоинт, который перенаправляется на DefaultFork, если он настроен. Это для совместимости URL со старыми установками Robust.Cdn.
GET /version/{version}/manifest
Запасной эндпоинт, который перенаправляется на DefaultFork, если он настроен. Это для совместимости URL со старыми установками Robust.Cdn.