Tyk Gateway в Docker Compose: готовый файл

MAATRIX

Когда за одним доменом стоит несколько сервисов, а каждому нужны свои ключи доступа, лимиты запросов и логи, писать это вручную в каждом сервисе — путь к дублированному коду и разному поведению. Tyk Gateway закрывает это одной точкой входа: open-source ядро на Go, конфигурация через JSON-файлы или REST API, и никакой обязательной коммерческой подписки для базового сценария. Ниже — рабочий docker-compose.yml с Redis, первый прокси-маршрут, ключи с лимитами и честный разбор того, что в open source есть, а что нет.

Что такое Tyk Gateway и зачем он между сервисами и внешним миром

Tyk — это семейство продуктов вокруг API-шлюза: сам Gateway (open source, Apache 2.0), Tyk Pump для выгрузки аналитики, Tyk Identity Broker для SSO и коммерческие Tyk Dashboard с Developer Portal поверх них. Основной прокси-движок и вся логика авторизации, лимитов и трансформации запросов живут в Gateway — и именно он бесплатен и достаточен, чтобы закрыть 90% типовых задач: маршрутизацию, аутентификацию по ключу или JWT, rate limiting per-consumer, квоты и базовое логирование.

Чем это отличается от того, что уже есть у большинства:

Если задача — просто отдать статику или проксировать пару сервисов по доменам, Traefik или Nginx проще и без лишних движущихся частей. Tyk оправдан, когда вы реально выдаёте доступ внешним или внутренним потребителям API и хотите управлять ключами, лимитами и версиями без правки кода каждого сервиса. По архитектуре Tyk ближе всего к Kong Gateway — разница в основном в хранилище (Redis против Postgres/DB-less) и в синтаксисе конфигов.

Архитектура: Gateway, Redis и файлы API-конфигураций

Открытая версия Tyk устроена проще, чем может показаться из документации, где много страниц посвящено коммерческому Dashboard. Реально нужны два компонента:

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

Сами API-конфигурации (кто и куда проксируется, какая аутентификация, какие лимиты) — это JSON-файлы. Gateway читает их из каталога app_path при старте и заново — по сигналу перезагрузки (через management API или SIGHUP процессу). Никакой отдельной базы для конфигов не нужно: файлы можно версионировать в git и катить через CI, как обычный конфиг.

Управление на лету (создание ключей, просмотр статуса) идёт через встроенный REST API Gateway — по префиксу /tyk/ на том же порту, что и прокси-трафик, защищённый общим секретом (secret в конфиге) в заголовке x-tyk-authorization. Это не панель с UI, а именно API, поверх которого при желании собирается своя автоматизация.

Готовый docker-compose.yml

Файл поднимает Redis с постоянным хранилищем и Gateway, который стартует только после того, как Redis прошёл healthcheck. Конфигурация Gateway лежит в отдельном tyk.conf, а API-описания и политики — в смонтированных каталогах, чтобы их можно было редактировать и коммитить в git без пересборки образа.

# docker-compose.yml
services:
  redis:
    image: redis:7-alpine
    container_name: tyk-redis
    restart: unless-stopped
    command: redis-server --appendonly yes
    volumes:
      - tyk_redis_data:/data
    healthcheck:
      test: ["CMD", "redis-cli", "ping"]
      interval: 5s
      timeout: 3s
      retries: 10
    networks:
      - tyk-net

  tyk-gateway:
    image: tykio/tyk-gateway:v5.7.0
    container_name: tyk-gateway
    restart: unless-stopped
    depends_on:
      redis:
        condition: service_healthy
    volumes:
      - ./tyk.conf:/opt/tyk-gateway/tyk.conf:ro
      - ./apps:/opt/tyk-gateway/apps
      - ./policies:/opt/tyk-gateway/policies
    ports:
      - "8080:8080"
    networks:
      - tyk-net

volumes:
  tyk_redis_data:

networks:
  tyk-net:
    driver: bridge

Проверьте на Docker Hub (hub.docker.com/r/tykio/tyk-gateway/tags) актуальный на момент установки тег вместо v5.7.0 из примера — образ выпускается достаточно часто, и жёстко прибитая версия избавит от сюрпризов при случайном docker compose pull.

Рядом — tyk.conf, минимально достаточный для старта:

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

Значение secret — это ключ доступа к management API (/tyk/...), а не пароль для проксируемого трафика. Сгенерируйте его командой openssl rand -hex 32 и храните так же, как любой другой секрет — не в публичном git-репозитории. Каталоги apps/ и policies/ создайте пустыми рядом с compose-файлом перед первым запуском:

mkdir -p apps policies
docker compose up -d

После старта curl http://localhost:8080/hello должен вернуть JSON со статусом pass — это встроенный health-check эндпоинт, полезный и для docker healthcheck, и для внешнего мониторинга.

Первый API: маршрут, ключи и rate limiting

Каждый проксируемый сервис описывается одним JSON-файлом в apps/. Вот минимальный пример без аутентификации — открытый прокси на внутренний бэкенд:

{
  "name": "Example API",
  "api_id": "example-api",
  "org_id": "1",
  "use_keyless": true,
  "definition": {
    "location": "header",
    "key": "x-api-version"
  },
  "version_data": {
    "not_versioned": true,
    "versions": {
      "Default": { "name": "Default" }
    }
  },
  "proxy": {
    "listen_path": "/example/",
    "target_url": "http://backend:3000/",
    "strip_listen_path": true
  },
  "active": true
}

listen_path — это путь, на который приходят внешние запросы, target_url — куда они реально проксируются, strip_listen_path убирает /example/ из пути перед отправкой на бэкенд. Сохраните файл и перезагрузите конфигурацию Gateway одним из двух способов:

# через management API (рекомендуемый способ)
curl -H "x-tyk-authorization: ВАШ_SECRET" \
  http://localhost:8080/tyk/reload/group

# либо сигналом процессу
docker compose exec tyk-gateway kill -HUP 1

Теперь включите аутентификацию по ключу — поменяйте use_keyless на false и добавьте блок auth:

{
  "use_keyless": false,
  "auth": {
    "auth_header_name": "Authorization"
  }
}

После перезагрузки создайте ключ с лимитом и квотой через тот же management API:

curl -H "x-tyk-authorization: ВАШ_SECRET" \
  -X POST http://localhost:8080/tyk/keys/create \
  -d '{
    "rate": 100,
    "per": 60,
    "quota_max": 10000,
    "quota_renewal_rate": 3600,
    "access_rights": {
      "example-api": {
        "api_id": "example-api",
        "api_name": "Example API",
        "versions": ["Default"]
      }
    }
  }'

rate/per задают лимит запросов в окне (в примере — 100 запросов в 60 секунд), quota_max/quota_renewal_rate — суточную/часовую квоту, которая сбрасывается по расписанию. В ответе придёт сам ключ — его клиент передаёт в заголовке Authorization при вызове /example/.... Изменить лимиты можно, вызвав PUT /tyk/keys/{key} с новыми значениями — без перезапуска Gateway, лимиты в Redis применяются сразу.

Портал разработчика: что реально в open source, а что только в платной части

Здесь стоит быть честным, потому что маркетинг вокруг Tyk часто смешивает продукты. Полноценный веб-портал для разработчиков — с каталогом API, самостоятельной регистрацией потребителей и выдачей ключей через UI — это часть коммерческого Tyk Dashboard / Tyk Enterprise Developer Portal, а не открытого Gateway. Сам по себе open-source Gateway такого UI не предоставляет.

Что действительно доступно бесплатно и полезно как замена «портала» для небольшой команды:

• Tyk Gateway с версии 4.x понимает API-описания в нативном формате OpenAPI (OAS) с расширением x-tyk-api-gateway — то есть один и тот же файл одновременно и документирует API, и настраивает шлюз, без переноса вручную между Swagger-файлом и конфигом Tyk.
• Этот же OAS-файл можно отдать любому self-hosted UI для документации — Swagger UI или Redoc — рядом в том же docker-compose, и получить читаемую страницу с описанием эндпоинтов без коммерческой подписки:

  swagger-ui:
    image: swaggerapi/swagger-ui
    container_name: tyk-docs
    restart: unless-stopped
    environment:
      SWAGGER_JSON: /specs/example-api.yaml
    volumes:
      - ./docs:/specs:ro
    ports:
      - "8081:8080"
    networks:
      - tyk-net

Это закрывает потребность «показать документацию по API», но не заменяет самостоятельную регистрацию и выдачу ключей через UI — это реальное ограничение open-source части. Если такой self-service критичен, честнее сразу смотреть в сторону Dashboard, а не дособирать портал вручную поверх голого Gateway.

Продакшн-нюансы: TLS, изоляция management API, бэкапы

Из коробки docker-compose выше не готов к продакшену как есть — вот что стоит поправить перед реальным трафиком.

TLS. Gateway в примере слушает голый HTTP на 8080. Терминировать TLS проще снаружи — через Traefik или Caddy перед Tyk, а сам Gateway оставить во внутренней docker-сети без прямого выхода наружу. Общие принципы структуры такого compose-стека на боевом сервере разобраны в статье про Docker Compose для продакшена на Ubuntu 24.04.

Изоляция management API. В примере выше и прокси-трафик, и /tyk/... эндпоинты идут через один и тот же порт — удобно для теста, но публиковать его наружу без ограничений не стоит: секрет в заголовке — единственная защита /tyk/. На проде закройте пути /tyk/* правилом в reverse proxy так, чтобы они были доступны только из внутренней сети или VPN, а публично торчали только реальные маршруты API.

Бэкапы. Состояние, которое жалко потерять, — это каталоги apps/ и policies/ (по сути, весь конфиг API) и данные Redis, где хранятся текущие ключи и их лимиты. Если каталоги конфигов уже в git, регулярный бэкап нужен в основном для volume Redis — том же способом, что и для других сервисов, например через BorgBackup в Docker Compose.

Ресурсы. Точных цифр производительности приводить не буду — они сильно зависят от размера запросов, числа активных ключей и включённой аналитики. Как стартовая точка для теста и небольшой нагрузки достаточно 1-2 vCPU и 1-2 ГБ RAM на связку Gateway + Redis; дальше смотрите по факту через docker stats и метрики Redis, а не полагайтесь на ориентир из статьи.

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