For the complete documentation index, see llms.txt. This page is also available as Markdown.

Приложения и версии

Узнайте о версионировании и приложениях — концепции и лучшие практики для более глубокого понимания.

📦 Приложения

Приложения объединяют серверные проекты. Такое разделение контекста особенно полезно, если вы:

  • работаете над несколькими играми или неигровыми проектами (сводный биллинг),

  • работаете над внешними проектами как со-разработчик (позже передать владение),

  • зависите от нескольких слабо связанных типов серверов с разными паттернами масштабирования или требованиями.

Вы можете управлять своими приложениями на Edgegap с помощью наших плагинов, панель управления, или нашего API.

🏷️ Версии приложения

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

  • сохранять совместимость между вашими клиентами и сервером,

  • сравнивать различные аспекты ваших постепенных релизов (производительность, мнение пользователей),

  • тестировать несколько версий приложения одновременно (разработка, контроль качества, staging, beta).

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

Вы можете управлять версиями вашего приложения на Edgegap с помощью нашей панель управления, или нашего API.

Каждая версия однозначно идентифицируется в своем родительском приложении по имени версии приложения. Вы свободны выбирать собственную схему именования. Вот несколько популярных примеров, чтобы вдохновить вас:

  • 2024.01.30-16.23.00-UTC - временные метки наглядны для хранения многих прошлых версий,

  • 1.1.0 - семантическое версионирование — отличный выбор для передачи масштаба изменений,

  • dev , staging, qa, prod - хранить только последнюю версию для каждой среды очень легко,

  • blue, green - версии можно использовать как алиасы для стратегии релиза с поэтапным обновлением.

Вы можете отключить любое приложение или версию в нашей панель управления чтобы защититься от человеческих (dev) ошибок.

Бесплатный тариф ограничен 2 приложениями, 2 версиями и 5 ГБ хранилища Container Registry.

Комбинируйте стратегии версионирования

Часто лучшее решение — это смесь стратегий версионирования, например:

  • использование временных меток или семантического версионирования для dev-сборок для более детального отслеживания;

  • сохраняя staging, qa и prod версии со специфичными для среды параметрами;

  • чередуя blue и green версии как алиасы для обновлений без простоя матчмейкинга.

🧱 Обязательные параметры

Эти базовые параметры должны быть всегда заданы.

Требования к ресурсам

Помимо имени версии, для создания новой версии требуется несколько параметров:

  • vCPU - сколько виртуальных единиц CPU нужно вашему приложению для работы (1024 единицы = 1 vCPU),

    • минимально допустимое количество vCPU — 0,25 vCPU (256 единиц),

    • эту настройку нельзя изменить у существующей версии приложения, нужно создать новую версию.

  • Память - сколько мегабайт ОЗУ нужно вашему приложению для работы (1024 МБ = 1 ГБ),

    • эту настройку нельзя изменить у существующей версии приложения, нужно создать новую версию.

  • GPU - сколько графических процессоров нужно вашему приложению для работы,

    • эта функция пока недоступна, пожалуйста, свяжитесь с нами, если вам интересно.

Наши серверные машины используют процессоры AMD/Intel с тактовой частотой 2,4 - 3,2 ГГц, в зависимости от локации. Чтобы убедиться, что у вашего сервера достаточно доступных ресурсов, напишите нам в Discord сообщества.

Сведения об образе

Эти параметры помогут нашей системе решить, какая сборка вашего сервера должна быть запущена позже:

  • Реестр - registry.edgegap.com если вы используете наш Container Registry,

    • чтобы использовать сторонний реестр, введите docker-учетные данные вашего стороннего реестра,

    • реестр служит общим хранилищем для ваших и чужих репозиториев.

  • Репозиторий образов - относится к выделенному репозиторию вашего приложения,

    • найдите все свои репозитории на странице Container Registry в нашей панели управления,

    • каждый репозиторий может включать несколько тегов образа вашего сервера.

  • Тег - относится к конкретному артефакту сборки (версии) образа вашего сервера,

    • наши плагины по умолчанию копируют значения тегов из имен версий приложения,

    • вы можете просмотреть локально сохраненные теги в Docker Desktop Images или с помощью CLI Docker.

  • Частный реестр - если доступ к вашему репозиторию защищен (частный репозиторий), нам также понадобятся:

Поиск и часто задаваемые вопросы

Я получил ошибку 401 Unauthorized при загрузке образа моего сервера.

  • Это означает, что вы не вошли в свой контейнерный реестр. См. Container Registry для инструкций по Edgegap Container Registry, или аналогичных для вашего поставщика реестра. Повтор последнего действия не устранит ошибку.


Я получил ошибку 403 Forbidden при загрузке образа моего сервера.

  • Это означает, что либо у пользователя реестра, под которым вы сейчас вошли, недостаточно прав (обычно для отправки нового образа), либо вы вошли не в того поставщика реестра. Попробуйте выйти и войти снова с правильным поставщиком и пользователем с достаточными правами. Повтор последнего действия не устранит ошибку.


В чем разница между реестром, репозиторием и проектом?

  • Представьте реестр как складское помещение, репозиторий как отдельную ячейку хранения, а проект как номер ячейки. Каждый реестр обычно включает много репозиториев: некоторые публичные, некоторые частные для организаций и пользователей.

  • Пример реестра: registry.edgegap.com .

  • Пример репозитория: registry.edgegap.com/my-edgegap-org/my-game-server.

  • Пример имени проекта: my-game-server .


При отправке новых тегов образов / сборок мои изменения не перезагружаются корректно.

  • Убедитесь, что каждый раз при пересборке вы отправляете с новым тегом образа. Внутренняя система кеширования Edgegap использует имена тегов, и если вы перезапишете значение тега (например, latest) он не подхватит новую сборку.


Могу ли я помечать один и тот же артефакт сборки несколькими тегами?

  • Да, вы можете без проблем назначать один и тот же артефакт несколькими тегами, используя их как несколько алиасов к одной и той же сборке. Продолжайте читать, чтобы узнать, как позже удалить теги.


Что происходит, когда я удаляю тег? Почему я не могу удалить конкретный артефакт по хэшу?

  • Удаление тега также приведет к удалению связанного артефакта сборки, если на момент запроса API.

  • Из-за стандартов API Docker и чтобы обеспечить наилучший пользовательский опыт, мы предоставляем только интерфейс для удаления тегов. См. выше о удалении артефактов сборки.

⚙️ Необязательные параметры

Эти параметры можно настроить, чтобы дополнительно адаптировать ваши развертывания.

Внедряемые переменные

Для всех развертываний этой версии будут внедряться пользовательские переменные окружения:

  • типичные примеры включают: аргументы движка, секреты и конечные точки сторонних сервисов,

  • см. Внедрённые переменные для понимания различных способов внедрения переменных окружения в зависимости от контекста развертывания, в дополнение к переменным версии приложения,

  • каждая переменная окружения может содержать до 4 КБ текстовых данных.

Активное кеширование

🌟 Перейдите на тариф Pay as You Go чтобы разблокировать время развертывания 0,5 секунды по всему миру!

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

Кеширование полностью вступит в силу, когда уровень кеширования вашей версии приложения достигнет 🟢 Хорошо.

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

Сопоставление портов

Каждому серверу требуется как минимум один порт, чтобы принимать входящие клиентские соединения:

  • Порт значение относится к внутреннему порту значение, обычно из вашей интеграции netcode,

  • Протокол будет зависеть от транспорта вашей интеграции netcode,

  • Имя — это читаемый человеком идентификатор для ваших собственных нужд, может совпадать с портом,

  • Проверки можно включить, чтобы убедиться, что ваш контейнер инициализирован до того, как будет помечен как READY.

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

Добавьте больше портов в сопоставление портов, если ваш сервер обменивается данными по нескольким протоколам.

Предохранительные ограничения

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

  • Ограничения по времени - эти функции могут помочь вам управлять жизненным циклом ресурсов развертываний:

  • Политика перезапуска процесса — управляет поведением развертывания, когда процесс вашего сервера останавливается.

    • Всегда перезапускать (по умолчанию) — перезапустит при успешном коде завершения (0) и любом завершении с ошибкой.

    • Никогда не перезапускать (рекомендуется) — развертывание останавливается при кодах завершения успеха и ошибки.

    • Перезапускать при сбое — перезапускать только при кодах завершения ошибки, полезно для постоянных серверов.

Бесплатный тариф ограничен 2 приложениями, 2 версиями и 5 ГБ хранилища Container Registry.

Хранилище журналов

Чтобы экспортировать журналы сервера после остановки развертывания, настройте Хранилище конечных точек с использованием S3 bucket.

⏩ Согласованность обновлений

Чтобы гарантировать, что при создании новой версии приложения через наш панель управления, мы рекомендуем использовать функцию Duplicate в правом верхнем углу страницы панели управления вашей предыдущей версии приложения. При дублировании вы можете изменить любые параметры перед сохранением.

См. Rolling Updates матчмейкера для дальнейшей автоматизации релизов.

Последнее обновление

Это было полезно?