reproxy v1.7.0
Servidor HTTP(S) de borde ligero y proxy inverso con SSL automático, descubrimiento Docker/Consul, autenticación por ruta, limitación de velocidad y conmutación por error basada en comprobaciones de salud.
Reproxy es un servidor/proxy inverso simple de borde HTTP(s) que admite varios proveedores (docker, estático, archivo, catálogo consul). Uno o más proveedores suministran información sobre el servidor solicitado, la URL solicitada, la URL de destino y la URL de verificación de salud. Se distribuye como un solo binario o como un contenedor docker.
- Terminación SSL automática con Let's Encrypt
- Soporte de certificados SSL proporcionados por el usuario
- Reglas de proxy simples pero flexibles
- Proveedor de reglas de proxy estático y de línea de comandos
- Proveedor de reglas de proxy dinámico basado en archivos
- Proveedor Docker con descubrimiento automático
- Proveedor de Catálogo Consul con descubrimiento por etiquetas de servicio
- Soporte para múltiples hosts (virtuales)
- Compresión de tráfico opcional
- Control de acceso basado en IP opcional
- Autenticación básica por ruta
- Límites de tamaño y tiempos de espera definidos por el usuario
- Distribución de un solo binario
- Distribución de contenedor Docker
- Servidor de activos estáticos integrado con modo "SPA amigable" opcional
- Soporte para reglas de redirección
- Limitador opcional para la actividad general y la actividad del usuario
- Verificación de salud en vivo y conmutación por error/balanceo de carga
- Servidor de gestión con información de rutas y métricas de Prometheus
- Soporte de plugins mediante RPC para implementar funcionalidad personalizada
- Registro opcional con formato de registro Apache e informes simplificados de stdout.
El servidor (host) puede configurarse como FQDN, ej. s.example.com, * (catch all) o una expresión regular. La coincidencia exacta tiene prioridad, por lo que si hay dos reglas con servidores example.com y example\.(com|org), la solicitud a example.com/some/url coincidirá con la primera. La URL solicitada puede ser una expresión regular, por ejemplo ^/api/(.*) y la URL de destino puede tener grupos coincidentes de la expresión regular, ej. http://d.example.com:8080/$1. Para el ejemplo anterior, http://s.example.com/api/something?foo=bar se proxyará a http://d.example.com:8080/something?foo=bar.
Por conveniencia, las solicitudes con / final y sin grupos de expresión regular se expanden a /(.*), y los destinos en esos casos se expanden a /$1. Es decir, /api/ -> http://127.0.0.1/service se traducirá a ^/api/(.*) -> http://127.0.0.1/service/$1.
La sustitución de host es compatible en la URL de destino. Por ejemplo, /files/${host} se reemplazará con el nombre del host coincidente. También se puede usar $host (sin llaves).
Se admiten tanto HTTP como HTTPS. Para HTTPS, se puede usar un certificado estático así como certificados ACME automatizados (Let's Encrypt). Se puede usar un servidor de activos opcional para servir archivos estáticos. Iniciar reproxy requiere al menos un proveedor definido. El resto de parámetros son estrictamente opcionales y tienen valores predeterminados razonables.
Ejemplos:
- con un proveedor estático:
reproxy --static.enabled --static.rule="*,example.com/api/(.*),https://api.example.com/$1" - con descubrimiento docker automático:
reproxy --docker.enabled --docker.auto - como contenedor docker:
docker up -p 80:8080 umputun/reproxy --docker.enabled --docker.auto - con SSL automático:
docker up -p 80:8080 -p 443:8443 umputun/reproxy --docker.enabled --docker.auto --ssl.type=auto --ssl.fqdn=example.com
Instalación
Reproxy se distribuye como un pequeño binario autónomo, así como una imagen docker. Tanto el binario como la imagen admiten múltiples arquitecturas y múltiples sistemas operativos, incluyendo linux_x86_64, linux_arm64, linux_arm, macos_x86_64, macos_arm64, windows_x86_64 y windows_arm. También proporcionamos paquetes deb y rpm tanto para arm64 como para x86.
- para una distribución binaria descargue el archivo adecuado en la sección de versiones
- para usuarios de Homebrew:
brew install umputun/apps/reproxy - el contenedor docker está disponible en Docker Hub así como en Github Container Registry. Ej.
docker pull umputun/reproxyodocker pull ghcr.io/umputun/reproxy.
La última versión estable tiene la etiqueta docker :vX.Y.Z (con el alias :latest) y la rama master actual tiene la etiqueta :master.
Proveedores
Las reglas de proxy son proporcionadas por varios proveedores. Actualmente incluidos - file, docker, static y consul-catalog. Cada proveedor puede definir múltiples reglas de enrutamiento tanto para solicitudes proxy como para activos estáticos. El usuario puede configurar múltiples proveedores al mismo tiempo.
Vea ejemplos de varios proveedores en examples
Proveedor estático
Este es el proveedor más simple que define todas las reglas de mapeo directamente en la línea de comandos (o entorno). Se admiten múltiples reglas. Cada regla tiene de 3 a 7 elementos separados por comas server,sourceurl,destination[,ping-url[,forward-health-checks[,timeout[,throttle]]]]. Por ejemplo:
*,^/api/(.*),https://api.example.com/$1- proxy todas las solicitudes a cualquier host/servidor con prefijo/apiahttps://api.example.comexample.com,/foo/bar,https://api.example.com/zzz,https://api.example.com/ping- proxy todas las solicitudes aexample.comy con url/foo/barahttps://api.example.com/zzzy usahttps://api.example.com/pingpara la verificación de salud.example.com,/foo/bar,https://api.example.com/zzz,https://api.example.com/ping,true- igual que el anterior pero también reenvía las solicitudes/pingy/healthal backend.example.com,^/upload/(.*),https://api.example.com/$1,,,5m- tiempo de espera de solicitud por ruta de 5 minutos (4to y 5to campos vacíos para omitir ping-url y forward-health-checks).example.com,^/login,https://api.example.com/login,,,,2- limitación por ruta de 2 req/seg por usuario (los campos posicionales anteriores están vacíos).
El 4º elemento define una url de ping opcional utilizada para informes de salud. El 5º elemento habilita opcionalmente el reenvío de solicitudes de verificación de salud al backend (true, yes, 1). Consulte la sección Verificación de salud para más detalles. El 6º elemento es un tiempo de espera de solicitud por ruta opcional (duración Go, ej. 5m, 30s); 0 o vacío hereda la configuración global --timeout.write. El 7º elemento es un límite opcional de req/seg por usuario por ruta; 0 o vacío hereda la configuración --throttle.user. Se permiten campos posicionales vacíos (ej. ,, para los campos intermedios no utilizados).
Proveedor de archivos
Este proveedor utiliza un archivo yaml con reglas de enrutamiento.
reproxy --file.enabled --file.name=config.yml