reproxy v1.7.0

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.

• Terminaison SSL automatique avec Let's Encrypt
• Prise en charge des certificats SSL fournis par l'utilisateur
• Règles de proxy simples mais flexibles
• Fournisseur de règles de proxy statique en ligne de commande
• Fournisseur de règles de proxy dynamique basé sur fichier
• Fournisseur Docker avec découverte automatique
• Fournisseur Consul Catalog avec découverte par tags de service
• Prise en charge de multiples hôtes (virtuels)
• Compression du trafic optionnelle
• Contrôle d'accès basé sur IP optionnel
• Authentification de base par route
• Limites de taille et délais d'attente définis par l'utilisateur
• Distribution en binaire unique
• Distribution en conteneur Docker
• Serveur d'actifs statiques intégré avec mode « SPA friendly » optionnel
• Prise en charge des règles de redirection
• Limiteur optionnel pour l'activité globale ainsi que pour l'activité de l'utilisateur
• Vérification de santé en direct et basculement/équilibrage de charge
• Serveur de gestion avec informations sur les routes et métriques Prometheus
• Prise en charge des plugins via RPC pour implémenter des fonctionnalités personnalisées
• Journalisation optionnelle avec à la fois le format Apache Log Format et des rapports stdout simplifiés.

---

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 :

• avec un fournisseur statique : reproxy --static.enabled --static.rule="*,example.com/api/(.*),https://api.example.com/$1"
• avec une découverte automatique docker : reproxy --docker.enabled --docker.auto
• en tant que conteneur docker : docker up -p 80:8080 umputun/reproxy --docker.enabled --docker.auto
• avec SSL automatique : docker up -p 80:8080 -p 443:8443 umputun/reproxy --docker.enabled --docker.auto --ssl.type=auto --ssl.fqdn=example.com

Installation

Reproxy 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.

• pour une distribution binaire, téléchargez le fichier approprié dans la section des versions
• pour les utilisateurs de Homebrew : brew install umputun/apps/reproxy
• le conteneur docker est disponible sur Docker Hub ainsi que sur Github Container Registry. C'est-à-dire docker 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.

Fournisseurs

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

Fournisseur statique

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.com
• example.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).

Fournisseur fichier

Ce fournisseur utilise un fichier yaml avec des règles de routage.