reproxy v1.7.0 — Lightweight edge HTTP(S) server and reverse proxy with automatic SSL, Docker/Consul discovery, per-route authentication, rate limiting, and health-check-based failover.

Reproxy — это простой edge HTTP(s)-сервер / обратный прокси с поддержкой различных провайдеров (docker, static, file, consul catalog). Один или несколько провайдеров предоставляют информацию о запрашиваемом сервере, запрашиваемом URL, целевом URL и URL проверки работоспособности. Распространяется в виде единого бинарного файла или docker-контейнера.

Автоматическое завершение SSL с помощью Let's Encrypt
Поддержка пользовательских SSL-сертификатов
Простые, но гибкие правила проксирования
Статический провайдер правил проксирования из командной строки
Динамический провайдер правил проксирования на основе файлов
Docker-провайдер с автоматическим обнаружением
Провайдер Consul Catalog с обнаружением по тегам сервисов
Поддержка нескольких (виртуальных) хостов
Опциональное сжатие трафика
Опциональный контроль доступа по IP
Базовая аутентификация для каждого маршрута
Пользовательские ограничения размера и тайм-ауты
Распространение в виде единого бинарного файла
Распространение в виде docker-контейнера
Встроенный сервер статических ресурсов с опциональным «SPA-дружественным» режимом
Поддержка правил перенаправления
Опциональный ограничитель как для общей активности, так и для активности пользователей
Проверка работоспособности в реальном времени и fail-over/балансировка нагрузки
Управляющий сервер с информацией о маршрутах и метриками prometheus
Поддержка плагинов через RPC для реализации пользовательской функциональности
Опциональное логирование как в формате Apache Log Format, так и в виде упрощённых отчётов в stdout.

Сервер (хост) может быть задан как FQDN, т.е. s.example.com, * (catch all) или регулярное выражение. Точное совпадение имеет приоритет, поэтому если есть два правила с серверами example.com и example\.(com|org), запрос к example.com/some/url будет соответствовать первому. Запрашиваемый URL может быть регулярным выражением, например ^/api/(.*), а целевой URL может содержать совпавшие группы регулярного выражения, т.е. http://d.example.com:8080/$1. Для примера выше http://s.example.com/api/something?foo=bar будет проксирован на http://d.example.com:8080/something?foo=bar.

Для удобства запросы с завершающим / и без групп регулярного выражения раскрываются в /(.*), а назначения в этих случаях раскрываются в /$1. Т.е. /api/ -> http://127.0.0.1/service будет преобразовано в ^/api/(.*) -> http://127.0.0.1/service/$1.

В целевом URL поддерживается подстановка хоста. Например, /files/${host} будет заменено на совпавшее имя хоста. Также можно использовать $host (без фигурных скобок).

Поддерживаются как HTTP, так и HTTPS. Для HTTPS можно использовать как статический сертификат, так и автоматические сертификаты ACME (Let's Encrypt). Опциональный сервер ресурсов может использоваться для раздачи статических файлов. Для запуска reproxy требуется как минимум один определённый провайдер. Остальные параметры строго опциональны и имеют разумные значения по умолчанию.

Примеры:

со статическим провайдером: reproxy --static.enabled --static.rule="*,example.com/api/(.*),https://api.example.com/$1"
с автоматическим обнаружением docker: reproxy --docker.enabled --docker.auto
как docker-контейнер: docker up -p 80:8080 umputun/reproxy --docker.enabled --docker.auto
с автоматическим SSL: docker up -p 80:8080 -p 443:8443 umputun/reproxy --docker.enabled --docker.auto --ssl.type=auto --ssl.fqdn=example.com

Установка

Reproxy распространяется как небольшой самодостаточный бинарный файл, а также как docker-образ. И бинарный файл, и образ поддерживают несколько архитектур и несколько операционных систем, включая linux_x86_64, linux_arm64, linux_arm, macos_x86_64, macos_arm64, windows_x86_64 и windows_arm. Мы также предоставляем пакеты deb и rpm для arm64 и x86.

для бинарной дистрибуции скачайте соответствующий файл в разделе релизов
для пользователей Homebrew: brew install umputun/apps/reproxy
docker-контейнер доступен на Docker Hub, а также в Github Container Registry. То есть docker pull umputun/reproxy или docker pull ghcr.io/umputun/reproxy.

Последняя стабильная версия имеет docker-тег :vX.Y.Z (с алиасом :latest), а текущий master имеет тег :master.

Провайдеры

Правила проксирования поставляются различными провайдерами. В настоящее время включены — file, docker, static и consul-catalog. Каждый провайдер может определять несколько правил маршрутизации как для проксируемых запросов, так и для статических (assets). Пользователь может задать несколько провайдеров одновременно.

Смотрите примеры различных провайдеров в examples

Статический провайдер

Это простейший провайдер, определяющий все правила сопоставления непосредственно в командной строке (или окружении). Поддерживается несколько правил. Каждое правило состоит из 3–7 элементов, разделённых запятыми: server,sourceurl,destination[,ping-url[,forward-health-checks[,timeout[,throttle]]]]. Например:

*,^/api/(.*),https://api.example.com/$1 — проксировать все запросы к любому хосту/серверу с префиксом /api на https://api.example.com
example.com,/foo/bar,https://api.example.com/zzz,https://api.example.com/ping — проксировать все запросы к example.com с url /foo/bar на https://api.example.com/zzz, при этом для проверки работоспособности используется https://api.example.com/ping.
example.com,/foo/bar,https://api.example.com/zzz,https://api.example.com/ping,true — то же, что выше, но также перенаправляет запросы /ping и /health на бэкенд.
example.com,^/upload/(.*),https://api.example.com/$1,,,5m — таймаут запроса для маршрута 5 минут (4-е и 5-е поля оставлены пустыми, чтобы пропустить ping-url и forward-health-checks).
example.com,^/login,https://api.example.com/login,,,,2 — ограничение частоты для маршрута 2 запроса/сек на пользователя (предшествующие позиционные поля оставлены пустыми).

4-й элемент задаёт необязательный ping url, используемый для отчётов о работоспособности. 5-й элемент опционально включает перенаправление запросов проверки работоспособности на бэкенд (true, yes, 1). Подробнее см. раздел Проверка работоспособности. 6-й элемент — необязательный таймаут запроса для маршрута (длительность Go, например 5m, 30s); 0 или пустое значение наследует глобальную настройку --timeout.write. 7-й элемент — необязательное ограничение запросов/сек на пользователя для маршрута; 0 или пустое значение наследует --throttle.user. Пустые позиционные поля допускаются (например, ,, для неиспользуемых средних полей).

Файловый провайдер

Этот провайдер использует yaml-файл с правилами маршрутизации.

reproxy --file.enabled --file.name=config.yml

Пример config.yml: