Автоматизация через API хостинга

MAATRIX GAMES

Если у тебя не один сервер, а пять-десять — под разные игры, под ивенты, под тестовые сборки — рано или поздно кликать по кнопкам в панели хостинга надоедает. Особенно когда одна и та же операция (рестарт, снапшот, поднять временный сервер под турнир) повторяется раз в неделю. Решение простое: у большинства хостинг-провайдеров с полноценной панелью есть REST API, и через него всё это можно автоматизировать — от одного bash-скрипта до полноценной интеграции в свою Discord-панель сообщества.

Что вообще умеет API хостинга

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

• Создание и удаление сервера — с указанием тарифа, локации, образа (игры), иногда стартовой конфигурации.
• Управление питанием — старт, стоп, рестарт, иногда мягкий рестарт (graceful, с ожиданием сохранения) и жёсткий (kill).
• Изменение тарифа — апгрейд/даунгрейд RAM и CPU, часто с возможностью запланировать на конкретное время, а не применить мгновенно.
• Снапшоты и бэкапы — снять снимок текущего состояния, посмотреть список существующих, восстановить сервер из снапшота.
• Статус и метрики — состояние сервера (running/stopped/restarting), базовая загрузка CPU/RAM, иногда аптайм.
• Управление файлами — у части провайдеров есть file-manager API: загрузить конфиг, скачать лог, без захода в панель руками.

Точный список эндпоинтов, лимиты запросов (rate limit) и формат ответов — всегда смотри в документации конкретного провайдера, у него это может называться иначе и иметь свои нюансы. Ниже — примеры на условном обобщённом API, чтобы показать логику, а не выдать готовый рабочий код под конкретного хостера.

Как устроен запрос: REST, токен, HTTP

Почти везде схема одна: REST API с авторизацией через Bearer-токен в заголовке. Получаешь токен в личном кабинете (обычно в разделе вроде "API" или "Токены доступа"), дальше каждый запрос — это HTTP-вызов с этим токеном.

Базовый пример на curl — получить список своих серверов:

curl -s -X GET "https://api.example-host.com/v1/servers" \
  -H "Authorization: Bearer $HOST_API_TOKEN" \
  -H "Content-Type: application/json"

Рестарт конкретного сервера по ID:

curl -s -X POST "https://api.example-host.com/v1/servers/12345/restart" \
  -H "Authorization: Bearer $HOST_API_TOKEN"

Ответ обычно приходит в JSON — с полем status, id задачи (если операция асинхронная, как создание сервера) и, часто, ссылкой, по которой можно опрашивать прогресс. Асинхронность — важный момент: команда "создать сервер" не значит, что сервер готов сразу после ответа 200 OK. Нужно либо поллить статус, либо (если провайдер поддерживает) подписаться на вебхук о завершении операции.

Сценарий 1: временный сервер под турнир

Классика для сообществ, которые устраивают разовые ивенты — турнир по CS2, PvP-ивент на Rust, ARK-сезон на выходные. Вместо того чтобы держать лишний сервер месяцами "на всякий случай", поднимаешь его скриптом за час до старта и удаляешь через сутки после.

Псевдокод сценария (адаптируй под реальные поля API своего провайдера):

#!/usr/bin/env bash
set -euo pipefail

TOKEN="$HOST_API_TOKEN"
API="https://api.example-host.com/v1"

# 1. Создаём сервер под турнир
RESPONSE=$(curl -s -X POST "$API/servers" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "cs2-tournament-2026-09",
    "game": "cs2",
    "plan": "8gb",
    "location": "eu-west"
  }')

SERVER_ID=$(echo "$RESPONSE" | jq -r '.id')
echo "Создан сервер $SERVER_ID"

# 2. Ждём готовности (простой поллинг раз в 10 сек, максимум 5 минут)
for i in $(seq 1 30); do
  STATUS=$(curl -s -H "Authorization: Bearer $TOKEN" \
    "$API/servers/$SERVER_ID" | jq -r '.status')
  [ "$STATUS" = "running" ] && break
  sleep 10
done

echo "Сервер готов, статус: $STATUS"

Удаление после турнира — отдельный скрипт (или продолжение этого же), который запускается по крону через 24-48 часов:

curl -s -X DELETE "$API/servers/$SERVER_ID" \
  -H "Authorization: Bearer $TOKEN"

Перед удалением обязательно сними финальный снапшот, если есть шанс, что данные ещё понадобятся (демки матчей, статистика) — восстановить после DELETE без бэкапа уже не получится. Про регулярные снимки состояния — в статье про автобэкапы игрового сервера.

Сценарий 2: массовый рестарт нескольких серверов

Если у тебя сеть из нескольких серверов (например, три Minecraft-сборки под разные режимы), удобно иметь один скрипт, который рестартует всё разом — после обновления плагинов, например, или при плановом окне обслуживания.

#!/usr/bin/env bash
set -euo pipefail

TOKEN="$HOST_API_TOKEN"
API="https://api.example-host.com/v1"

# Список ID серверов — можно хранить в отдельном файле servers.txt
SERVER_IDS=("11001" "11002" "11003")

for id in "${SERVER_IDS[@]}"; do
  echo "Рестарт сервера $id..."
  HTTP_CODE=$(curl -s -o /dev/null -w "%{http_code}" \
    -X POST "$API/servers/$id/restart" \
    -H "Authorization: Bearer $TOKEN")

  if [ "$HTTP_CODE" -ne 200 ] && [ "$HTTP_CODE" -ne 202 ]; then
    echo "Ошибка на сервере $id, код $HTTP_CODE" >&2
  fi
  sleep 5  # пауза между запросами, чтобы не упереться в rate limit
done

Такой скрипт можно повесить на cron — например, каждую пятницу в 4 утра по серверному времени, если у тебя выходит еженедельный патч. Про то, как оформить сам cron-джоб для рестарта, подробнее — в статье про автоматический рестарт по расписанию. Отдельный нюанс: для игр, где важно не рестартовать сервер посреди активного боя или рейда (тот же ARK или Rust на пике онлайна), стоит сначала дёрнуть RCON-команду с предупреждением игрокам, и только потом — API-рестарт. Про RCON — в статье про подключение и команды RCON.

Сценарий 3: статус серверов в своей панели сообщества

Многие админы держат для игроков свою мини-панель — сайт сообщества, бот в Discord, страничку со статусами. Через API хостинга можно подтягивать реальное состояние серверов (запущен/остановлен/на рестарте) вместо того, чтобы полагаться только на игровой A2S-запрос (который может не ответить, даже если сервер физически жив, — например, если игровой процесс завис, а сама VM работает).

Логика простая: раз в минуту дёргаешь /servers/{id} по API хостинга и пишешь статус в свою БД или кэш, дальше отдаёшь на фронтенд или в Discord-эмбед.

import requests
import time

TOKEN = "..."  # берём из переменной окружения, не хардкодим
API = "https://api.example-host.com/v1"

def get_status(server_id: str) -> str:
    r = requests.get(
        f"{API}/servers/{server_id}",
        headers={"Authorization": f"Bearer {TOKEN}"},
        timeout=10,
    )
    r.raise_for_status()
    return r.json().get("status", "unknown")

while True:
    status = get_status("11001")
    # здесь — запись в БД / обновление embed'а в Discord-боте
    print(f"server 11001: {status}")
    time.sleep(60)

Если у тебя уже есть Discord-бот для управления сервером, туда же логично добавить и статус-команду поверх API хостинга — не только игровые RCON-команды, но и "жив ли вообще инстанс". Как собрать такого бота с нуля — в статье про Discord-бота для управления игровым сервером. Если задача — именно долгосрочный мониторинг аптайма с алертами, а не просто статус на сайте, лучше не изобретать поллинг заново, а посмотреть готовые инструменты для этого.

Ограничение частоты запросов и обработка ошибок

API почти всегда лимитирован — типичная защита от абьюза, обычно что-то вроде N запросов в минуту на токен. Если ты пишешь скрипт, который дёргает статус нескольких серверов в цикле, легко в этот лимит упереться, особенно если крутишь поллинг раз в несколько секунд.

Практические правила:

• Проверяй HTTP-код ответа: 429 Too Many Requests — сигнал притормозить, а не повторять запрос немедленно.
• Реализуй retry с экспоненциальной задержкой (1с, 2с, 4с, 8с...) вместо жёсткого цикла без пауз.
• Для регулярного мониторинга статуса выбирай интервал поллинга разумно — раз в 30-60 секунд обычно достаточно, раз в секунду — уже избыточно и рискует упереться в лимит.
• Логируй все API-вызовы автоматизации отдельно от игровых логов — когда скрипт что-то не то удалил или не так рестартовал, разбираться проще по отдельному логу действий, а не искать иголку в общем краш-репорте.

Безопасность: где хранить токен и как ограничить права

API-токен — это по сути пароль от твоей инфраструктуры: с ним можно создавать, удалять, рестартовать серверы. Пара правил, которые стоит соблюдать с самого начала, а не после первого инцидента:

• Никогда не хардкодь токен в коде скрипта. Даже если репозиторий приватный — токен в коммите рано или поздно куда-то утечёт (форк, скриншот, случайный публичный репо). Храни его в переменной окружения:

export HOST_API_TOKEN="твой_токен_сюда"

или в .env-файле, который добавлен в .gitignore и никогда не коммитится:

HOST_API_TOKEN=твой_токен_сюда

• Ограничивай права токена, если провайдер это поддерживает. Часть хостеров даёт создавать несколько токенов с разным scope — например, один только на чтение статуса (для панели статусов сообщества), другой — с правом рестарта, но без права удаления серверов. Если у бота для статус-панели украдут токен, лучше, чтобы им нельзя было снести весь парк серверов.
• Ротация токена — если провайдер разрешает, периодически перевыпускай токен и отзывай старый, особенно если он использовался в нескольких местах (личный ноутбук, CI, сервер бота).
• Не отдавай токен на сторонние сервисы, которые просят его "для интеграции", если это не официальный партнёр хостера — токен даёт доступ ровно ко всей твоей инфраструктуре под этим аккаунтом.
• Если скрипты автоматизации крутятся на отдельной VM или в CI (например, GitHub Actions), храни токен в secrets этой системы (GitHub Secrets, переменные окружения раннера), а не в файле репозитория.

Частые вопросы