Одна из наиболее важных задач при разделении системы на микросервисы - обеспечить надежный механизм их репликации и обнаружения и создать набор правил для маршрутизации входящих запросов к соответствующим контейнерам или сетевым узлам. Идеальная система также должна уметь отслеживать состояние доступности и исключать недоступные реплики из маршрутизации. В этой статье мы поговорим об использовании маршрутизатора Kong, который принимает на себя не только задачи умной маршрутизации, но и возможности по протоколированию и трансформации запросов, контролю доступа, мониторингу запросов, а также может быть расширен с использованием плагинов.

Маршрутизатор Kong Gateway существует в свободном и коммерческом варианте, может быть запущен как самостоятельное приложение (например, через docker-контейнер kong), либо установлен в Kubernetes (в этом случае он представляется как специализированный Ingress-контроллер). Для управления Kong можно использовать как запросы к API, так и веб-интерфейсы Kong Manager или Konga. Многие расширения предустановлены в официальном контейнере, но они также могут быть найдены в Kong Plugin Hub. Мы с вами рассмотрим установку и настройку на примере простого приложения, состоящего из трех микросервисов (один из которых представляет публичный интерфейс без авторизации, для одного мы будем задавать сложные правила маршрутизации, а третий будет требовать обязательное использование токена для доступа к точкам подключения).

Для начала составим топологию нашей системы и выделим микросервисы:

• сервис поиска местоположения и расширенной информации о городе по стране и названию (используется приложение Chercheville на Elixir , доступное на Docker Hub);

• сервис для получения информации из профиля авторизованного пользователя;

• сервис для выполнения авторизации и получения токена.

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

Kong использует для сохранения своей конфигурации базу данных PostgreSQL, либо может быть запущен с определением сервисов и привязок к json/yaml-файле. Мы будем рассматривать вариант запуска с базой данных. Для координации запуска будем использовать Docker Compose, который можно найти в официальном репозитории: https://github.com/Kong/docker-kong (путь /compose).

docker compose --profile database up -d

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

• 8000/8443 - HTTP/HTTPS-трафик для маршрутизации к серверам;

• 8001/8444 - HTTP/HTTPS порты для отправки административных запросов (также используется веб-интерфейсом Konga для управления ресурсами);

• 8002/8445 - HTTP/HTTPS подключение к Kong Manager (веб-интерфейс), должен быть дополнительно разрешен и опубликован через docker-compose.yaml.

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

• Service - конфигурация backend-сервиса (протокол http/https, адрес хоста, порт, количество попыток подключения и таймауты, идентификатор клиентского сертификата при использовании https). К конфигурации сервиса могут быть подключены плагины для аудита/трансформации запросов, а также определены допустимые потребители (consumer).

• Route - правило маршрутизации входящих запросов, включает в себя перечисления связанных сервисов (может быть больше одного для отказоустойчивости) и группу фильтров (для http-протоколов) или набор правил для tcp-stream маршрутизации. К каждому маршруту может быть также добавлен плагин для обработки запросов.

  • название домена (Hosts);

  • префиксы пути (Paths);

  • HTTP-методы (Methods);

  • протоколы (http / https);

  • проверка доменов для tcp-stream маршрутизации (SNI);

  • источники запроса для tcp-stream (sources);

  • получатели запроса для tcp-stream (destinations).

• Certificate - зарегистрированные клиентские сертификаты для подключения к https backend-сервисам (для каждого формируется уникальный id, который используется при конфигурации сервиса).

• Upstream - правило пересылки http/https трафика на один или несколько сервисов. После создания и настройки upstream появляется возможность добавить targets (ip/dns-адреса целевых серверов, порты и значение веса, которое влияет на вероятность выбора сервера при использовании хэш-правила none), а также Alert для отправки уведомлений администраторам по почте или в Slack при недоступности целевого сервера:

  • Hash on - метод хэширования для выбора целевого сервиса из пула (может быть consumer, ip, cookie, header, none). В случае none используется последовательный выбор сервисов для равномерного распределения;

  • Hash fallback - альтернативный метод хэширования, если основной не вернул результат (например, отсутствовал cookie или заголовок);

  • Active Health Check - конфигурация проверки доступности (http-метод, путь, коды успешных и неуспешных ответов, количество попыток проверки, интервал проверки);

• Consumer - зарегистрированные авторизованные пользователи сервисов и метод их авторизации. Для Consumer определяется набор Credentials - это может быть Basic Auth (имя и пароль), API Key, Hash-based message authentication code (HMAC) - имя и секрет, OAuth2 (id и секрет приложения, redirect uri), JSON Web Token (JWT).

Для управления ресурсами можно использовать http-запросы к порту администрирования 8001 (или 8444 для https-запросов):

• http://ip:8001/services - просмотр списка/регистрация нового сервиса;

• http://ip:8001/routes - просмотр/создание маршрута;

• http://ip:8001/consumers - управление авторизованными пользователями;

• http://ip:8001/upstreams - изменение правил проксирования с проверкой доступности (upstream);

• http://ip:8001/certificates - управление клиентскими сертификатами;

• http://ip:8001 - просмотр информации о запущенном экземпляре kong.

Для удобства доступа можно создать маршрут к admin api через основной порт (8000):

curl -X POST http://127.0.0.1:8001/services \
  --data name=admin-api \
  --data host=127.0.0.1 \
  --data port=8001

curl -X POST http://127.0.0.1:8001/services/admin-api/routes \
  --data paths[]=/admin-api

И далее будет возможно получить доступ к сервису администрирования через http://localhost:8000/admin-api/. Наличие API для администрирования позволяет выполнить саморегистрацию сервиса и маршрута при запуске, но сейчас у нас доступ к api выполняется без авторизации, что нельзя назвать безопасным решением. Создадим новый consumer с APIKey и назначим его на доступ к маршруту api:

curl -i -X POST \
  --url http://localhost:8001/services/admin-api/plugins/ \
  --data 'name=key-auth'

curl -i -X POST \
  --url http://localhost:8000/admin-api/consumers/ \
  --data "username=admin"
  
curl -i -X POST \
  --url http://localhost:8000/admin-api/consumers/admin/key-auth/ \
  --data 'key=6Y6fKCsFWWWSRMXGyUWs8g9q'

Теперь доступ к API будет происходить только с использованием заголовка apikey: 6Y6fKCsFWWWSRMXGyUWs8g9q.

Кроме плагинов авторизации, можно добавить следующие расширения:

• session - отслеживание сессии между запросами (чаще всего с использованием cookie);

• bot detection - обнаружение активности ботов;

• cors - управление политикой cors;

• ip restriction - ограничение доступа по белым и черным спискам;

• acme - интеграция с letsencrypt для автоматического обновления сертификатов;

• rate limiting - ограничение количества запросов в секунду;

• response ratelimiting - ограничение количества ответов в секунду;

• request size limiting - ограничение размера запроса;

• proxy cache - кэширование ответа;

• pre function - запустить lua-функцию перед обработкой запроса;

• post function - запустить lua-функцию после обработки запроса;

• aws lambda - запустить внешнюю функцию с AWS при обработке правила;

• azure functions - запустить Azure-функцию при обработке правила;

• datadog - отправить метрики запросов в datadog;

• prometheus - отправить метрики по правилам в prometheus;

• zipkin - отправка меток по обработке правил для распределенной трассировки zipkin;

• request transformer - изменение запроса перед передачей на upstream-сервер;

• response transformer - изменение ответа upstream-сервера;

• correlation ID - отслеживание связи в цепочке пересылок;

• tcp/udp/http log - отправка информации о запросе и ответе на сервер журналирования через tcp/udp/http;

• file log - запись информации о запросе/ответе в файл;

• syslog - отправка запроса и ответа в системный процесс syslog;

• statsd - отправка статистики по обработке запроса в statsd;

• loggly - пересылка информации о запросе/ответе в loggly.

При необходимости создания собственных расширений можно использовать Python Developent Kit.

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

docker network create konga
docker rm -f konga-db
docker run -d --network=konga --name konga-db -v /data/mongo:/data/db mongo
docker rm -f konga2
docker run -d --network=konga --name konga -e NODE_ENV=production -e "TOKEN_STRING=fdoER#2sa" -e DB_ADAPTER=mongo -e DB_HOST=konga-db -e DB_DATABASE=konga --network=konga -p 443:1337 -v /data/konga:/data -e SSL_KEY_PATH=/data/cert.key -e SSL_CRT_PATH=/data/cert.crt pantsel/konga

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

Запустим теперь наш сервис для маршрутизации и выполним привязку его методов к префиксу /place. Для этого клонируем репозиторий и запустим docker compose up -d. После запуска будет необходимо выполнить импорт данных по странам:

docker exec -ti chercheville-app-1 sh
./bin/chercheville rpc 'ChercheVille.SeedData.import_data(["FR"])'

Для проверки доступности сервиса выполним запрос http://localhost:5000/cities/?q=Paris. Теперь выполним связывание сервиса и маршрута через konga:

Здесь Host - внешний адрес сервера (альтернативно можно использовать DNS-имя во внутренней сети или через используемый Service Discovery, например Consul). Дальше необходимо настроить привязку сервиса к внешнему маршруту:

Strip Path позволяет трансформировать адрес и убрать префикс /places при пересылке запроса. Теперь сервис будем доступен через адрес http://localhost:8000/places/ и можно будет выполнить запрос между микросервисами или от внешнего клиента через API Gateway.

Следующим шагом выполним саморегистрацию сервиса авторизации в kong, который также будет управлять Consumer для доступа к сервису профиля:

import requests
import socket
from flask import Flask

gateway = "http://localhost:8000"
kong_api = f"{gateway}/admin-api"
headers = {
    "apikey": "6Y6fKCsFWWWSRMXGyUWs8g9q"
}

hostname = socket.gethostname()
local_ip = socket.gethostbyname(hostname)

# саморегистрация сервиса
requests.post(f"{kong_api}/services", headers=headers, data={
    "name": "authorizer",
    "url": "http://{local_ip}:10080"
})
requests.post(f"{kong_api}/services/authorizer/routes", data={
    "paths[]=/auth"
})

app = Flask(__name__)


@app.route("/login")
def login():
    # extract and check login/password
    login = "login"
    requests.post(f"{kong_api}/consumers", data={"username": login})  # регистрируем consumer


@app.route("/logout")
def logout():
    requests.delete(f"{kong_api}/consumers/{login}")


app.run(port=10080)

При регистрации сервиса profile необходимо добавить плагин key-auth для проверки токена при обращении к адресам profile. При авторизации будет добавлен заголовок X-Consumer-ID для хранения идентификатора, который соответствует представленному токену.

import requests
import socket
import json
import flask

gateway = "http://localhost:8000"
kong_api = f"{gateway}/admin-api"
headers = {
    "apikey": "6Y6fKCsFWWWSRMXGyUWs8g9q"
}

hostname = socket.gethostname()
local_ip = socket.gethostbyname(hostname)

# саморегистрация сервиса
requests.post(f"{kong_api}/services", headers=headers, data={
    "name": "profile",
    "url": "http://{local_ip}:9080"
})
requests.post(f"{kong_api}/services/profile/routes", data={
    "paths[]=/profile"
})
requests.post(f"{kong_api}/services/profile/plugins", data={
    "name=key-auth"
})
app = flask.Flask(__name__)


@app.route("/profile")
def login():
  consumers = json.loads(requests.get(f"{kong_api}/consumers"))
  # определение имени (идентификатора) пользователя
  # список содержит id (consumer id) и имя пользователя (name)
  id = flask.request.headers.get("X-Consumer-ID")
  username = None
  for c in consumers:
    if c["id"]==id:
       username = c["username"]
  if not username:
    flask.abort(403, "Not authorized")
  return f"Logged user: {username}"


app.run(port=9080)

Аналогично можно настроить удаление сервисов и маршрутов при завершении приложения. Таким образом с использованием API-шлюза Kong можно динамически изменять привязку маршрутов к экземплярам сервисов, а также решать типичные задачи контроля доступа и получения метрик по времени выполнения запросов.

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

• Зарегистрироваться на вебинар