umputun/reproxyServeur HTTP(S) de périphérie léger et proxy inverse avec SSL automatique, découverte Docker/Consul, authentification par route, limitation de débit, et basculement basé sur les vérifications de santé.
Reproxy est un serveur edge HTTP(s) / proxy inverse simple supportant divers fournisseurs (docker, static, file, consul catalog). Un ou plusieurs fournisseurs fournissent des informations sur le serveur demandé, l'URL demandée, l'URL de destination et l'URL de vérification de santé. Il est distribué sous forme de binaire unique ou de conteneur docker.
Le serveur (hôte) peut être défini comme un FQDN, c'est-à-dire s.example.com, * (tous) ou une expression régulière. La correspondance exacte a priorité, donc s'il y a deux règles avec les serveurs example.com et example\.(com|org), la requête vers example.com/some/url correspondra à la première. L'URL demandée peut être une regex, par exemple ^/api/(.*) et l'URL de destination peut contenir des groupes correspondant à la regex, c'est-à-dire http://d.example.com:8080/$1. Pour l'exemple ci-dessus, http://s.example.com/api/something?foo=bar sera proxyfié vers http://d.example.com:8080/something?foo=bar.
Par commodité, les requêtes avec un / final et sans groupes regex sont étendues à /(.*), et les destinations dans ces cas sont étendues à /$1. C'est-à-dire /api/ -> http://127.0.0.1/service sera traduit en ^/api/(.*) -> http://127.0.0.1/service/$1.
La substitution d'hôte est prise en charge dans l'URL de destination. Par exemple, /files/${host} sera remplacé par le nom d'hôte correspondant. $host (sans accolades) peut également être utilisé.
HTTP et HTTPS sont tous deux pris en charge. Pour HTTPS, un certificat statique peut être utilisé ainsi que des certificats ACME automatisés (Let's Encrypt). Un serveur d'actifs optionnel peut être utilisé pour servir des fichiers statiques. Démarrer reproxy nécessite au moins un fournisseur défini. Le reste des paramètres est strictement optionnel et a des valeurs par défaut raisonnables.
Exemples :
reproxy --static.enabled --static.rule="*,example.com/api/(.*),https://api.example.com/$1"reproxy --docker.enabled --docker.autodocker up -p 80:8080 umputun/reproxy --docker.enabled --docker.autodocker up -p 80:8080 -p 443:8443 umputun/reproxy --docker.enabled --docker.auto --ssl.type=auto --ssl.fqdn=example.comReproxy est distribué sous forme d'un petit binaire autonome ainsi que d'une image docker. Le binaire et l'image supportent de multiples architectures et systèmes d'exploitation, notamment linux_x86_64, linux_arm64, linux_arm, macos_x86_64, macos_arm64, windows_x86_64 et windows_arm. Nous fournissons également des paquets deb et rpm pour arm64 et x86.
brew install umputun/apps/reproxydocker pull umputun/reproxy ou docker pull ghcr.io/umputun/reproxy.La dernière version stable a le tag docker :vX.Y.Z (avec l'alias :latest) et le master actuel a le tag :master.
Les règles de proxy sont fournies par divers fournisseurs. Actuellement inclus - file, docker, static et consul-catalog. Chaque fournisseur peut définir plusieurs règles de routage pour les requêtes proxyfiées et les actifs statiques. L'utilisateur peut définir plusieurs fournisseurs en même temps.
Voir des exemples de divers fournisseurs dans examples
C'est le fournisseur le plus simple, définissant toutes les règles de correspondance directement en ligne de commande (ou environnement). Plusieurs règles supportées. Chaque règle est composée de 3 à 7 éléments séparés par des virgules server,sourceurl,destination[,ping-url[,forward-health-checks[,timeout[,throttle]]]]. Par exemple :
*,^/api/(.*),https://api.example.com/$1 - proxyfie toute requête vers tout hôte/serveur avec le préfixe /api vers https://api.example.comexample.com,/foo/bar,https://api.example.com/zzz,https://api.example.com/ping - proxyfie toutes les requêtes vers example.com et avec l'URL /foo/bar vers https://api.example.com/zzz et utilise https://api.example.com/ping pour la vérification de santé.example.com,/foo/bar,https://api.example.com/zzz,https://api.example.com/ping,true - identique à ci-dessus mais transmet également les requêtes /ping et /health au backend.example.com,^/upload/(.*),https://api.example.com/$1,,,5m - délai d'attente de requête par route de 5 minutes (4e et 5e champs laissés vides pour ignorer ping-url et forward-health-checks).example.com,^/login,https://api.example.com/login,,,,2 - limitation par route de 2 req/s par utilisateur (les champs positionnels précédents sont laissés vides).Le 4e élément définit une URL ping facultative utilisée pour le rapport de santé. Le 5e élément active éventuellement la transmission des requêtes de vérification de santé au backend (true, yes, 1). Voir la section Vérification de santé pour plus de détails. Le 6e élément est un délai d'attente de requête facultatif par route (durée Go, par exemple 5m, 30s); 0 ou vide hérite du paramètre global --timeout.write. Le 7e élément est une limite facultative de req/s par utilisateur par route ; 0 ou vide hérite de --throttle.user. Les champs positionnels vides sont autorisés (par exemple ,, pour les champs intermédiaires inutilisés).
Ce fournisseur utilise un fichier yaml avec des règles de routage.