L'agent en tant que reverse proxy

La méthode d'intégration de redirection.io la plus simple et la plus recommandée consiste à utiliser l'agent redirection.io en tant que reverse proxy, en exploitant les fonctionnalités natives qu'il propose.

Ce reverse proxy dispose de nombreuses directives de configuration, ce qui s'avère utile dans de nombreuses situations pour installer redirection.io sur votre infrastructure de manière performante, simple et évolutive.

Comment fonctionne le reverse proxy de l'agent redirection.io ?

Le reverse proxy de l'agent redirection.io est un reverse proxy sans état (stateless) très simple et direct :

• il accepte les connexions entrantes, en http ou en https
• il inspecte les requêtes entrantes afin d'appliquer toute règle correspondante
• si aucune règle ne correspond, il transmet la requête au backend de votre choix - soit en http, soit en https

Comme tout reverse proxy, l'agent redirection.io peut être répliqué sur votre infrastructure. Si vous avez besoin de plus d'un agent dans votre architecture, vous pouvez bien sûr dupliquer l'instance / le pod / le conteneur. Voici quelques propriétés du reverse proxy de l'agent redirection.io :

• il est rapide et peut inspecter plusieurs milliers de requêtes par seconde (et même plus)
• il supporte les architectures multi-projets
• c'est un binaire sans dépendance. L'agent est distribué sous forme de paquet APT ou RPM, et il est également disponible sous forme d'archive .tar.gz
• il peut être supervisé en utilisant l'endpoint de métriques de l'agent
• comme tout reverse-proxy, il est scalable en lançant davantage d'instances de l'agent

Quelles sont les principales fonctionnalités du reverse proxy de l'agent redirection.io ?

Le reverse proxy de l'agent redirection.io offre de nombreuses fonctionnalités :

• des performances très élevées, même avec un grand nombre de règles
• le support de http1, http2 et http3 (quic)
• le support des backends http et https, avec ou sans certificats valides
• la gestion des certificats SSL via Let's Encrypt (avec renouvellement automatique) ou en utilisant vos propres certificats
• le support des headers de transfert (X-Forwarded-* ou Forwarded), pour transmettre les propriétés de la requête originale au backend
• le support des architectures multi-projets et des Virtualhosts
• une configuration très flexible des timeouts et de nombreuses options d'optimisation des performances
• des fonctionnalités de base de mise en cache http, avec support des headers Cache-Control et Vary

Quelques exemples de configurations de proxies

En tant que reverse proxy autonome, l'agent redirection.io peut facilement être configuré pour fonctionner dans tous les types d'architectures :

• comme première couche de votre trafic entrant, pour le trafic http et https, avec terminaison SSL
• derrière d'autres reverse proxies
• derrière un serveur nginx ou Apache
• en tant que gestionnaire de trafic, entre plusieurs micro-services de votre application
• devant une API, pour détecter des problèmes dans les requêtes réelles
• devant une application legacy, pour empêcher qu'elle ne soit accédée sur des URL invalides ou via des méthodes non-GET
• devant un site web statique, pour appliquer des redirections et des règles sans changer la configuration de l'hébergement

Cette section donne un aperçu de la manière d'insérer le reverse proxy redirectionio-agent dans votre pile web existante.

Un Virtualhost de serveur web traditionnel, sans redirection.io

Prenez un VirtualHost nginx standard et simple. La configuration nginx définit généralement plusieurs directives (nom du serveur, port d'écoute, racine du document, etc.). Ce sera notre exemple de base dans les chapitres suivants (l'approche avec un autre serveur Web, comme Apache, serait très similaire).

L'agent redirection.io en tant que reverse proxy http qui forwarde les requêtes vers un backend http

L'agent redirection.io intègre un reverse proxy complet et performant. Dans l'architecture suivante, l'agent reçoit les requêtes http sur le port 8080 et les transmet au serveur nginx sur le port 8081 :

Recevoir du trafic http et https, avec terminaison SSL

L'agent redirection.io peut être configuré pour agir comme un point de terminaison SSL. Par exemple :

Dans cette architecture :

• l'agent reçoit toutes les requêtes entrantes, sur les ports 80 et 443. Il accepte les protocoles http1, http2 et http3 (quic)
• un certificat SSL sous forme de fichier local est configuré pour l'agent (/path/to/ssl/cert/pem et /path/to/ssl.key)
• les requêtes sont transmises au serveur backend en http (non https)
• il transmet ces requêtes à un serveur nginx disponible localement, sur le port 8080, en http (non https)
• les requêtes sont transmises en utilisant les headers de requête X-Forwarded-*, afin que votre backend puisse avoir connaissance des propriétés de la requête originale.

L'agent peut également être configuré pour utiliser un certificat Let's Encrypt au lieu d'un certificat fichier local :

Vous pouvez même combiner les certificats "locaux" et les certificats "Let's Encrypt" en même temps, pour utiliser le fichier local au démarrage et éviter toute interruption de service, puis laisser l'agent renouveler automatiquement le certificat via Let's Encrypt.

Transmettre des requêtes vers un backend https

Dans l'architecture ci-dessus, l'agent transmet les requêtes au backend via le protocole http. Dans certains cas, cela peut ne pas suffire à vos contraintes ou obligations. L'agent est également capable de transmettre les requêtes en utilisant https - avec un certificat valide ou invalide (si allow_invalid_certificates est activé) :

Le reverse proxy intégré de l'agent redirection.io supporte le SNI et de nombreuses options de configuration pour gérer la connexion SSL vers le backend. Consultez la documentation détaillée sur le transfert de requêtes pour plus de détails sur les options disponibles.

Exposer le système de fichiers local

Il est possible d'utiliser un répertoire local comme backend pour le reverse proxy de l'agent redirection.io. Ceci est utile si vous souhaitez utiliser l'agent comme reverse proxy devant un site web statique, par exemple.

Questions et réponses

Puis-je utiliser l'agent comme reverse proxy pour plusieurs sites web ?

Oui, l'agent supporte le multi-projets. En d'autres termes, vous pouvez utiliser le même processus de reverse proxy redirection.io pour gérer le trafic de plusieurs sites web déployés sur la même infrastructure mutualisée (bien que vous puissiez préférer séparer les stacks, mais c'est une autre considération).

En utilisant le concept de "virtualhosts", l'agent redirection.io peut router les requêtes entrantes vers le bon projet, selon le domaine de la requête. C'est un moyen très pratique de gérer plusieurs sites web avec une seule instance d'agent redirection.io. L'agent peut écouter sur les ports 80 et 443, et router les requêtes vers le bon projet en fonction du domaine de la requête.

Voir l'exemple suivant :

La configuration pour réaliser cette architecture est assez simple. La clé de configuration virtual_hosts vous permet de définir plusieurs virtualhosts, chacun d'eux étant associé à un projet et un ensemble de domaines. L'agent routera ensuite les requêtes entrantes vers le bon projet, selon le domaine de la requête.

instance:
    name: 'My Instance'
reverse_proxy:
    listen:
        - 'tcp://0.0.0.0:80'
        - 'tls://0.0.0.0:443'
        - 'quic://0.0.0.0:443'
    virtual_hosts:
        -
            domains:
                - example.com
            forward:
                address: '127.0.0.1:8080'
            agent:
                project_key: FIRST_PROJECT_KEY
            certificate:
                file:
                    key: /path/to/example-com-cert.key
                    certificates:
                        - /path/to/example-com-cert.pem
        -
            domains:
                - other-website.com
            forward:
                address: '127.0.0.1:8081'
            agent:
                project_key: SECOND_PROJECT_KEY
            certificate:
                file:
                    key: /path/to/other-website-com-cert.key
                    certificates:
                        - /path/to/other-website-com-cert.pem

Dans cette architecture :

• l'agent reçoit des requêtes http et https (sur les ports 80 et 443)
• selon le domaine de la requête, il route les requêtes vers l'un des serveurs backend (sur les ports 8080 ou 8081)

Par défaut, les requêtes sont transmises au backend en utilisant le même header Host que celui de la requête entrante. Cela signifie que, dans l'exemple ci-dessus, le serveur backend (ex: nginx, etc.) recevra des requêtes avec le header Host réglé sur example.com ou other-website.com, selon le domaine de la requête entrante. Dans ce cas, il est bien sûr possible d'utiliser cette valeur dans le serveur backend lui-même pour gérer plusieurs virtualhosts :

Du point de vue de redirection.io, cela peut être réalisé avec cette configuration simple :

instance:
    name: 'My Instance'
reverse_proxy:
    listen:
        - 'tcp://0.0.0.0:80'
        - 'tls://0.0.0.0:443'
        - 'quic://0.0.0.0:443'
    forward:
        address: '127.0.0.1:8080'
    virtual_hosts:
        -
            domains:
                - example.com
            agent:
                project_key: FIRST_PROJECT_KEY
            certificate:
                file:
                    key: /path/to/example-com-cert.key
                    certificates:
                        - /path/to/example-com-cert.pem
        -
            domains:
                - other-website.com
            agent:
                project_key: SECOND_PROJECT_KEY
            certificate:
                file:
                    key: /path/to/other-website-com-cert.key
                    certificates:
                        - /path/to/other-website-com-cert.pem

Comment puis-je scaler l'agent ?

L'agent est très performant, mais vous voudrez sûrement scaler / mutualiser / répartir son utilisation sur vos serveurs. Cela peut être fait simplement en lançant plusieurs instances du processus.

Dans une architecture de serveurs statiques, lancer plusieurs fois le redirectionio-agent est tout à fait acceptable. Prenez soin de donner à chaque instance un nom unique, afin de pouvoir la reconnaître par la suite dans l'"écran des instances" de l'interface graphique du manager (et recevoir des notifications si une instance n'est pas à jour).

Notez que nous fournissons un rôle Ansible pour installer et configurer l'agent.

Dans les environnements dynamiques, il est également tout à fait autorisé de lancer autant d'instances de l'agent que nécessaire, dès que des pics de trafic apparaissent. Afin de définir un nom unique pour chaque instance de l'agent, n'oubliez pas que vous pouvez utiliser des variables d'environnement dans la configuration de l'agent.

Je ne peux pas modifier le flux de requêtes dans mon infrastructure, puis-je quand même utiliser redirection.io sur mon site web ?

Oui, il existe de nombreuses façons d'utiliser redirection.io sans utiliser l'agent comme reverse proxy. Si vous n'êtes pas en mesure d'ajouter un reverse proxy devant votre serveur backend, vous pouvez toujours utiliser redirection.io via nos modules nginx ou Apache, ou même nos intégrations avec Cloudflare, Fastly, Vercel, etc. Consultez la page de documentation des intégrations disponibles pour plus de détails sur les modes d'intégration proposés.

Performances attendues

En tant que reverse proxy, l'agent redirection.io est un logiciel que vous voudrez surveiller avec prudence. Il fournit un endpoint de supervision intégré qui expose plusieurs métriques de santé.

Le reverse proxy de redirection.io est extrêmement performant. Nous ne fournissons pas de chiffres bruts, mais il surpasse largement les serveurs web classiques du marché pour exécuter des redirections sous forte charge et/ou avec un grand nombre de règles de redirection configurées. Consultez notre page de documentation sur les performances pour plus de détails.