Tyk Gateway на Ubuntu 24.04: пошаговая установка

MAATRIX

Когда за одной точкой входа нужно спрятать несколько внутренних сервисов, выдать каждому клиенту отдельный ключ и ограничить его по числу запросов, дописывать это в Nginx-конфиг через map-блоки и самописные lua-скрипты — плохая идея: логика размазывается по файлам, а любая правка лимита требует ручного редактирования и перезапуска. Tyk Gateway — открытый API-шлюз, у которого маршрутизация, аутентификация по ключам и рейт-лимиты встроены как обычная функциональность, а не костыль поверх веб-сервера. Ниже — пошаговая установка Tyk Gateway на чистом Ubuntu 24.04: от Redis и репозитория пакетов до первого рабочего API-определения с лимитом запросов и API-ключом.

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

Tyk Gateway — самостоятельный процесс на Go, который принимает входящий HTTP-трафик, сверяет его с загруженными API-определениями и проксирует на нужный бэкенд, попутно считая квоты и лимиты. Исходный код открыт на GitHub, и именно эта часть экосистемы Tyk — Gateway — бесплатна и устанавливается на свой сервер без привязки к облаку вендора.

Важный нюанс, который стоит понимать сразу: у Tyk есть более крупная линейка продуктов — Dashboard (веб-панель управления), Tyk Pump (выгрузка аналитики во внешние хранилища) и отдельный портал разработчика для публикации документации API внешним потребителям. Это отдельные компоненты со своими условиями лицензирования, и часть из них — платные или доступны как SaaS. Сам Gateway, который мы ставим в этой статье, для базовой работы шлюза — маршрутизации, ключей доступа и рейт-лимитов — их не требует: все API-определения можно писать и обновлять JSON-файлами или через встроенный административный API самого Gateway. Если позже понадобится портал для внешних разработчиков — уточняйте актуальные условия на сайте Tyk отдельно, к установке шлюза это не относится.

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

Подготовка сервера

Возьмите чистый VPS с Ubuntu 24.04 и root-доступом. Для теста и небольшой нагрузки хватит 2 vCPU и 2 ГБ RAM — Gateway и Redis на одной машине много не съедают, но под ощутимый продакшн-трафик закладывайте 4 ГБ и выше, особенно если включите полную аналитику запросов. Обновите систему перед установкой:

apt update && apt upgrade -y

Gateway по умолчанию слушает порт 8080. На боевом сервере наружу его лучше не открывать вовсе — снаружи должен быть только реверс-прокси с TLS (например, Nginx — как его настроить, разобрано в статье про Nginx как реверс-прокси на Ubuntu 24.04), а 8080 остаётся доступен только локально или из внутренней сети. Пока настраиваем и тестируем, откройте порт временно:

ufw allow 22/tcp
ufw allow 8080/tcp
ufw enable

После того как повесите перед Gateway реверс-прокси с TLS, правило для 8080 из фаервола стоит убрать — подробно про настройку самого UFW есть отдельная статья про фаервол UFW на Ubuntu 24.04. Локацию сервера выбирайте по тому, откуда идёт трафик к вашим API: RU — для аудитории в России, US и UK — если бэкенды и клиенты преимущественно за рубежом.

Redis — обязательная зависимость Tyk

Поставьте Redis из стандартного репозитория Ubuntu — для одного инстанса Gateway этого достаточно:

apt install -y redis-server
systemctl enable --now redis-server

По умолчанию Redis слушает только 127.0.0.1, что и нужно — снаружи он быть доступен не должен. Проверьте, что сервис поднялся и отвечает:

redis-cli ping

Ответ PONG означает, что Redis готов. Для продакшн-нагрузки имеет смысл включить persistence (AOF) в /etc/redis/redis.conf и следить за использованием памяти — если Redis упадёт или потеряет данные, Gateway потеряет счётчики лимитов и активные ключи, поэтому на серьёзном проекте бэкапьте этот инстанс так же аккуратно, как основную базу.

Установка Tyk Gateway на Ubuntu 24.04

Tyk распространяет свежие сборки Gateway через собственный репозиторий на packagecloud.io. Подключите его установочным скриптом и поставьте пакет:

curl -s https://packagecloud.io/install/repositories/tyk/tyk-gateway/script.deb.sh | sudo bash
apt-get install -y tyk-gateway

Честный нюанс: скрипт packagecloud определяет кодовое имя дистрибутива автоматически, а поддержка свежих релизов Ubuntu в репозиториях сторонних вендоров обычно отстаёт от официального выхода версии. Если после подключения репозитория apt-get install не находит пакет или ругается на codename, откройте файл списка репозитория и явно укажите более раннюю LTS-ветку, под которую Tyk точно публикует сборки:

cat /etc/apt/sources.list.d/tyk_tyk-gateway.list

Замените в этой строке кодовое имя на jammy (Ubuntu 22.04), сохраните файл и повторите apt update && apt-get install -y tyk-gateway. Deb-пакет Gateway не завязан на специфику ядра или системных библиотек 24.04 настолько, чтобы это ломало установку — это рабочий обходной путь, но не официально заявленная поддержка, так что после установки стоит внимательно проверить версию и логи запуска.

После установки Gateway разворачивается в /opt/tyk-gateway/: там лежат конфиг tyk.conf, каталог apps/ для API-определений и логи. Управляется процесс через systemd:

systemctl status tyk-gateway

Конфигурация tyk.conf и первый запуск

Откройте основной конфиг /opt/tyk-gateway/tyk.conf — это обычный JSON-файл. На старте важны несколько полей:

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

secret — не пароль конечных пользователей API, а ключ для управления самим Gateway, поэтому обращайтесь с ним как с root-паролем: не коммитьте в репозиторий, храните в переменных окружения или секрет-менеджере. Сохраните файл и перезапустите сервис:

systemctl restart tyk-gateway
journalctl -u tyk-gateway -f

В логах должна появиться строка о старте Gateway без ошибок подключения к Redis. Проверьте health-эндпоинт:

curl http://localhost:8080/hello

В ответ приходит JSON со статусом pass — это значит, что процесс жив и слушает порт.

Первое API-определение, ключи и рейт-лимиты

API-определения Gateway читает как JSON-файлы из каталога app_path. Создайте демонстрационное определение, которое проксирует запросы на внешний тестовый сервис и требует ключ доступа:

{
  "name": "demo-api",
  "api_id": "demo-api",
  "org_id": "1",
  "use_keyless": false,
  "auth": { "auth_header_name": "Authorization" },
  "version_data": {
    "not_versioned": true,
    "versions": { "Default": { "name": "Default" } }
  },
  "proxy": {
    "listen_path": "/demo/",
    "target_url": "https://httpbin.org",
    "strip_listen_path": true
  },
  "active": true
}

Сохраните файл как /opt/tyk-gateway/apps/demo-api.json и подхватите его без полного рестарта — через горячую перезагрузку по административному API (используйте secret из tyk.conf):

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

Определение с use_keyless: false требует ключ на каждый запрос, поэтому без него Gateway ответит 401. Создайте ключ с лимитом 100 запросов в минуту и квотой 1000 запросов в час через тот же административный API:

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

В ответе придёт key_hash и сам ключ. Используйте его в заголовке Authorization, чтобы проверить, что маршрутизация и лимит работают:

curl -H "Authorization: полученный-ключ" http://localhost:8080/demo/get

Запрос уходит на httpbin.org через Gateway, а после превышения 100 запросов в минуту Tyk начнёт отвечать 429 без обращения к бэкенду вообще — это и есть смысл шлюза: лимиты и авторизация отсекаются на входе, а не в коде каждого сервиса. На боевом сервере такой демо-эндпоинт удалите и опишите реальные API-определения для ваших внутренних сервисов, а Gateway закройте за реверс-прокси с TLS и фаерволом — заодно стоит поставить Fail2ban на Ubuntu 24.04, чтобы банить IP за подбор ключей доступа по 401-ответам в логах.

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