Как установить и настроить Tyk Gateway на VPS

MAATRIX

Когда за одним доменом прячется несколько бэкендов и каждому нужны свои ключи доступа, лимиты запросов и документация для внешних разработчиков, городить это руками поверх Nginx быстро надоедает. Tyk Gateway — open-source API-шлюз, который берёт на себя маршрутизацию, авторизацию по ключам, rate limiting и отдаёт партнёрам аккуратный портал с документацией — без покупки коммерческой панели. Разберём установку с нуля: Docker Compose с Redis, первый проксируемый API и включение встроенного портала разработчика.

Что такое Tyk Gateway и когда он нужен

Tyk Gateway — это прокси-сервер на Go, который стоит перед вашими API и решает три задачи разом: маршрутизирует запросы к нужному бэкенду, проверяет ключи доступа и считает лимиты, и собирает аналитику по вызовам. В отличие от Traefik или Nginx, которые умеют проксировать и балансировать, Tyk изначально заточен под API-менеджмент — у него из коробки есть сущности «ключ доступа», «политика с лимитами» и «версия API», а не только маршрут до бэкенда.

Открытая часть — Tyk Gateway CE (Community Edition) — не требует лицензии и покрывает основной сценарий: проксирование REST/GraphQL API, аутентификацию по API-ключам, OAuth2 и JWT, квоты и rate limiting, а также — начиная со сравнительно недавних версий — облегчённый встроенный портал разработчика прямо в самом гейтвее, без отдельной коммерческой Dashboard. Полноценный Tyk Enterprise Developer Portal с брендированием, платными планами и биллингом — это уже коммерческий продукт, но для показа каталога API документации и самостоятельной выдачи ключей встроенного портала обычно достаточно.

Ставить Tyk имеет смысл, если у вас несколько независимых сервисов за одним входом, если внешние клиенты (партнёры, мобильное приложение, сторонние разработчики) должны получать собственные ключи с лимитами, или если нужна единая точка авторизации перед микросервисами. Для одного внутреннего API без внешних потребителей это избыточно — там хватит Nginx или Traefik с базовой аутентификацией.

Подготовка VPS и Docker

Tyk Gateway сам по себе лёгкий процесс на Go, но ему нужен Redis как обязательное хранилище состояния — там живут ключи, счётчики лимитов и кэш конфигурации. Для гейтвея, Redis и одного-двух проксируемых сервисов комфортно стартовать с 2 ядер и 4 ГБ RAM, с запасом под рост трафика и число API. Если Docker ещё не установлен:

curl -fsSL https://get.docker.com | sh
systemctl enable --now docker

Локацию сервера выбирайте по географии клиентов ваших API: для аудитории из России и СНГ логичнее RU-площадка, для интеграций с зарубежными сервисами — US или UK. У MAATRIX доступны все три локации, оплата картой российского банка, через СБП или криптовалютой — можно не привязывать инфраструктуру к иностранному платёжному методу.

Создайте рабочую директорию и папку для файловых определений API — в CE-редакции без Dashboard они обычно хранятся как JSON-файлы на диске:

mkdir -p ~/tyk/{apps,logs}
cd ~/tyk

Redis и Tyk Gateway в Docker Compose

Опишем оба сервиса в одном compose.yaml. Redis держим во внутренней сети без публикации портов наружу, гейтвей — с портом 8080, который дальше можно спрятать за реверс-прокси с TLS:

services:
  redis:
    image: redis:7-alpine
    restart: unless-stopped
    volumes:
      - redis-data:/data
    networks:
      - tyk-net

  tyk-gateway:
    image: tykio/tyk-gateway:v5.7
    restart: unless-stopped
    depends_on:
      - redis
    ports:
      - "8080:8080"
    volumes:
      - ./tyk.conf:/opt/tyk-gateway/tyk.conf
      - ./apps:/opt/tyk-gateway/apps
      - ./logs:/opt/tyk-gateway/logs
    networks:
      - tyk-net

volumes:
  redis-data:

networks:
  tyk-net:

Тег образа стоит свериться с актуальным на Docker Hub перед запуском — версии Tyk выходят часто, а конфигурационные ключи между мажорными релизами иногда меняются. Перед первым запуском нужен файл tyk.conf, поэтому создайте его до docker compose up.

Первый API: tyk.conf и определение маршрута

Минимальный tyk.conf в корне проекта:

{
  "listen_port": 8080,
  "secret": "замените-на-длинную-случайную-строку",
  "storage": {
    "type": "redis",
    "host": "redis",
    "port": 6379
  },
  "app_path": "/opt/tyk-gateway/apps",
  "use_db_app_configs": false,
  "enable_analytics": true
}

Поле secret — это не пароль пользователя, а токен для обращения к управляющему Gateway API самого Tyk (эндпоинты вида /tyk/...), сгенерируйте его случайной строкой и никому не показывайте. use_db_app_configs: false означает, что определения API гейтвей читает как JSON-файлы из app_path, а не из базы Dashboard — это и есть файловый режим CE-редакции.

Теперь определим сам проксируемый API — файл apps/httpbin.json:

{
  "name": "httpbin-demo",
  "api_id": "httpbin-demo",
  "org_id": "default",
  "use_keyless": false,
  "auth": { "auth_header_name": "Authorization" },
  "definition": { "location": "header", "key": "x-api-version" },
  "version_data": {
    "not_versioned": true,
    "versions": { "Default": { "name": "Default" } }
  },
  "proxy": {
    "listen_path": "/httpbin/",
    "target_url": "https://httpbin.org/",
    "strip_listen_path": true
  },
  "active": true
}

listen_path — под каким путём API доступен снаружи через Tyk, target_url — реальный бэкенд, strip_listen_path: true убирает префикс /httpbin/ перед проксированием дальше. Запустите стек:

docker compose up -d
docker compose logs -f tyk-gateway

В логах должно появиться сообщение о загрузке API-определений. Гейтвей подхватывает файлы из apps/ при старте; для «горячей» перезагрузки после правки JSON без перезапуска контейнера есть управляющий вызов:

curl -H "x-tyk-authorization: замените-на-длинную-случайную-строку" \
  http://localhost:8080/tyk/reload/group

Ключи доступа и встроенный портал разработчика

Раз use_keyless: false, без ключа запрос к /httpbin/ вернёт 401. Создать ключ через тот же Gateway API:

curl -H "x-tyk-authorization: замените-на-длинную-случайную-строку" \
  -X POST http://localhost:8080/tyk/keys/create \
  -d '{
    "allowance": 1000,
    "rate": 1000,
    "per": 60,
    "expires": 0,
    "access_rights": {
      "httpbin-demo": { "api_id": "httpbin-demo", "versions": ["Default"] }
    }
  }'

Ответ содержит key_id — его клиент передаёт заголовком Authorization. Поля rate/per задают лимит: в примере 1000 запросов за 60 секунд, при превышении Tyk сам вернёт 429 без нагрузки на бэкенд.

Встроенный портал разработчика (появился в относительно свежих версиях Tyk Gateway CE, точный синтаксис включения стоит сверить с документацией под установленную версию) даёт внешним потребителям каталог опубликованных API с документацией и форму на получение ключа без ручной работы админа — то есть закрывает базовый сценарий self-service, ради которого раньше был нужен платный Dashboard. Для публикации API в портале в его JSON-определении добавляют флаг публичности и ссылку на OpenAPI-спецификацию; сам портал поднимается на отдельном пути (в конфиге типично секция вида "enable_portal": true с указанием пути и брендинга). Если после обновления версии флаги не сработали как ожидалось — это нормально для быстро развивающегося продукта, проверяйте changelog конкретного релиза.

Безопасность: закрыть Gateway API и добавить TLS

Порт 8080 отдаёт и проксируемые API, и управляющий Gateway API под /tyk/ — последний обязательно должен быть недоступен из интернета, иначе любой найдёт secret перебором или логами и получит полный контроль над гейтвеем. Проще всего ограничить доступ файрволом: внешний трафик пускать только на путь /httpbin/ и подобные, а /tyk/ разрешать лишь с локального IP или из VPN. Базовые правила файрвола UFW на VPS — обязательный первый шаг перед тем, как открывать гейтвей наружу.

TLS сам Tyk Gateway тоже умеет терминировать, но на практике удобнее поставить перед ним отдельный реверс-прокси с авто-выпуском сертификатов — например, Traefik на VPS, который берёт на себя Let's Encrypt и проксирует уже HTTPS-трафик на порт 8080 Tyk по внутренней сети Docker. Так сертификаты обновляются отдельно от логики API-шлюза, и обновление одного компонента не трогает другой.

Отдельно проверьте, что redis-data том с содержимым Redis не публикуется наружу и бэкапится — в нём хранятся все активные ключи доступа, и его потеря означает, что клиентам придётся перевыпускать ключи заново. Если Redis у вас уже настроен для других сервисов, частые ошибки Redis на сервере стоит держать под рукой — Tyk сразу теряет часть функциональности при недоступности хранилища.

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