reproxy v1.7.1

Reproxy es un servidor HTTP(s) de borde / proxy inverso simple que admite varios proveedores (docker, estático, archivo, catálogo de consul). Uno o más proveedores suministran información sobre el servidor solicitado, la URL solicitada, la URL de destino y la URL de comprobación de estado. Se distribuye como un único binario o como un contenedor docker.

• Terminación SSL automática con Let's Encrypt
• Compatibilidad con certificados SSL proporcionados por el usuario
• Reglas de proxy simples pero flexibles
• Proveedor de reglas de proxy estático, por línea de comandos
• Proveedor de reglas de proxy dinámico, basado en archivos
• Proveedor Docker con descubrimiento automático
• Proveedor Consul Catalog con descubrimiento por etiquetas de servicio
• Compatibilidad con múltiples hosts (virtuales)
• Compresión de tráfico opcional
• Control de acceso opcional basado en IP
• Autenticación básica por ruta
• Límites de tamaño y tiempos de espera definidos por el usuario
• Distribución como binario único
• Distribución como contenedor Docker
• Servidor de recursos estáticos integrado con modo opcional "compatible con SPA"
• Compatibilidad con reglas de redirección
• Limitador opcional para la actividad general así como para la actividad del usuario
• Comprobación de estado en vivo y fail-over/balanceo de carga
• Servidor de gestión con información de rutas y métricas de prometheus
• Compatibilidad con plugins vía RPC para implementar funcionalidad personalizada
• Registro opcional tanto con Apache Log Format como con informes simplificados en stdout.

---

El servidor (host) se puede establecer como FQDN, es decir, s.example.com, * (comodín) o una regex. La coincidencia exacta tiene prioridad, por lo que si hay dos reglas con los servidores example.com y example\.(com|org), la solicitud a example.com/some/url coincidirá con la primera. La URL solicitada puede ser una regex, por ejemplo ^/api/(.*), y la URL de destino puede tener grupos coincidentes de la regex, es decir, http://d.example.com:8080/$1. Para el ejemplo anterior, http://s.example.com/api/something?foo=bar se redirigirá a http://d.example.com:8080/something?foo=bar.

Por conveniencia, las solicitudes con la barra final / y sin grupos de regex 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 con 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 recursos 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 automático de docker: 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 autocontenido, así como una imagen de docker. Tanto el binario como la imagen soportan 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 releases
• para usuarios de Homebrew: brew install umputun/apps/reproxy
• contenedor docker disponible en Docker Hub, así como en Github Container Registry. Es decir, docker pull umputun/reproxy o docker pull ghcr.io/umputun/reproxy.

La última versión estable tiene la etiqueta docker :vX.Y.Z (con el alias :latest) y el master actual tiene la etiqueta :master.

Proveedores

Reglas de proxy suministradas por varios proveedores. Actualmente incluidos: file, docker, static y consul-catalog. Cada proveedor puede definir múltiples reglas de enrutamiento tanto para solicitudes proxied como para estáticos (assets). El usuario puede establecer múltiples proveedores al mismo tiempo.

Consulte ejemplos de varios proveedores en examples

Proveedor static

Este es el proveedor más simple, que define todas las reglas de mapeo directamente en la línea de comandos (o en el entorno). Se admiten múltiples reglas. Cada regla consta 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 - redirige todas las solicitudes a cualquier host/servidor con el prefijo /api a https://api.example.com
• example.com,/foo/bar,https://api.example.com/zzz,https://api.example.com/ping - redirige todas las solicitudes a example.com y con la url /foo/bar a https://api.example.com/zzz y consulta https://api.example.com/ping para el health check.
• 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 /ping y /health al backend.
• example.com,^/upload/(.*),https://api.example.com/$1,,,5m - timeout de solicitud por ruta de 5 minutos (los campos 4.º y 5.º se dejan vacíos para omitir ping-url y forward-health-checks).
• example.com,^/login,https://api.example.com/login,,,,2 - throttle por ruta de 2 req/seg por usuario (los campos posicionales anteriores se dejan vacíos).

El 4.º elemento define una url de ping opcional utilizada para el reporte de salud. El 5.º elemento habilita opcionalmente el reenvío de solicitudes de health check al backend (true, yes, 1). Consulte la sección Health check para más detalles. El 6.º elemento es un timeout de solicitud opcional por ruta (duración de Go, p. 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 --throttle.user. Se permiten campos posicionales vacíos (p. ej. ,, para los campos intermedios no utilizados).

Proveedor file

Este proveedor utiliza un archivo yaml con reglas de enrutamiento.

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

Ejemplo de config.yml: