L'agent en tant que reverse proxy

La méthode d'intégration redirection.io la plus simple consiste à utiliser l'agent redirection.io comme proxy inverse (reverse proxy en anglais), en tirant parti des fonctionnalités intégrées offertes par l'agent.

Le reverse-proxy de l'agent redirection.io propose de nombreuses directives de configuration, qui devraient être utiles 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, très simple et direct :

il accepte les connexions entrantes, en http ou 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 - en http ou https

Comme tout reverse-proxy, l'agent redirection.io peut être répliqué dans 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 prend en charge les architectures multi-projets
c'est un binaire sans dépendance. L'agent est distribué en tant que paquet APT ou RPM, et il est également disponible sous forme d'archive .tar.gz
il peut être surveillé à l'aide du point de terminaison des métriques de l'agent
comme tout reverse-proxy, il est évolutif, en lançant davantage d'instances de l'agent

Quelques exemples de configurations de proxy

En tant que reverse-proxy autonome, l'agent redirection.io peut facilement être configuré dans de nombreux types d'architectures.

comme première couche de votre trafic entrant
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 les problèmes dans les requêtes réelles

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

Une architecture traditionnelle et minimaliste

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 prochains chapitres (l'approche avec un autre serveur web, comme Apache, serait très similaire).

L'agent redirection.io en tant que reverse-proxy

L'agent redirection.io regroupe un reverse-proxy complet et très performant. Voyez comment nous avons modifié notre architecture d'infrastructure précédente en introduisant le reverse-proxy de l'agent redirection.io :

Dans cette architecture :

l'agent reçoit toutes les requêtes entrantes, sur les ports 80 et 443
il transmet ces requêtes à un serveur nginx disponible localement, sur le port 8080
les requêtes sont transmises en utilisant les en-têtes de requête X-Forwarded-*, afin que votre backend puisse connaître les propriétés de la requête originale.

Dans l'architecture ci-dessus, l'agent transmet les requêtes au backend en utilisant le protocole http. Dans certains cas, cela pourrait ne pas suffire à vos besoins. L'agent est également capable de transmettre les requêtes en utilisant https - avec un certificat valide ou un certificat invalide (dans ce cas, utilisez la directive de configuration allow_invalid_certificates) :

Le reverse-proxy de redirection.io derrière un autre reverse-proxy

Le reverse-proxy de redirection.io a une limitation : il ne prend pas en charge le SNI et ne fournit pas de moyens de configurer les suites de chiffrement. Les directives de configuration SSL offertes par le reverse-proxy de redirection.io sont plutôt spartiates, et non aussi détaillées et complètes que celles fournies par d'autres logiciels de terminaison SSL.

Pour cette raison, vous pourriez vouloir placer le reverse-proxy de redirection.io derrière un autre serveur proxy, qui agira alors comme votre point de terminaison SSL. Par exemple, c'est ce que nous pouvons réaliser avec nginx (mais vous pouvez aussi bien utiliser Varnish, HAProxy, Envoy, etc.) :

Redirection.io avec le module dynamique nginx

Comme alternative au déploiement utilisant le mode "reverse-proxy", le module nginx de redirection.io est un moyen rapide d'intégrer redirection.io dans votre infrastructure. Ce module dynamique s'insère simplement dans la boucle de requête et de réponse de nginx, et interroge de manière synchrone une API tcp de l'agent installé localement chaque fois qu'une requête arrive.

Bien que cette approche soit intéressante - car elle implique peu de changements dans l'architecture de l'infrastructure et le flux des requêtes dans votre pile - elle peut parfois être difficile à configurer :

premièrement, les modules dynamiques nginx sont liés à des versions très spécifiques de nginx. Nous distribuons des modules pré-compilés pour les versions de nginx fournies officiellement par les distributions, mais nous ne pouvons pas distribuer un module nginx pour chaque version disponible de nginx. En d'autres termes, les utilisateurs d'installations nginx personnalisées devront compiler le module nginx eux-mêmes
le flux de gestion des requêtes nginx n'est pas un voyage tranquille 🙂 En d'autres termes, selon les modules installés, des comportements inattendus peuvent apparaître, et il n'y a aucun moyen de garantir que notre module s'intégrera parfaitement à votre installation nginx. Par exemple, il pourrait y avoir des incompatibilités avec d'autres modules
les modules dynamiques nginx sont développés en langage C, ce qui ne garantit pas la sécurité de la mémoire. L'agent redirection.io lui-même, et la bibliothèque sous-jacente opensource libredirectionio, sont des binaires basés sur Rust
la mise à jour d'un module dynamique nécessite un redémarrage du serveur, ce qui n'est pas toujours souhaitable
enfin et surtout, l'utilisation du module nginx de redirection.io signifie que, pour chaque requête, un appel TCP synchrone est effectué du processus nginx vers l'agent redirection.io. Nous proposons plusieurs directives d'ajustement pour maintenir un pool de connexions, et cela fonctionnera parfaitement sur des sites web à trafic raisonnable, mais cela peut devenir un peu difficile à configurer correctement dans des environnements très exigeants

C'est pourquoi nous recommandons généralement d'utiliser plutôt le mode reverse-proxy. Cependant, le module nginx est un moyen parfaitement pratique, pris en charge et entièrement testé d'utiliser redirection.io si vous le souhaitez.

Aperçus et questions

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

Oui, l'agent prend en charge plusieurs projets. En d'autres termes, vous pouvez utiliser le même processus de reverse-proxy de 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 vouloir séparer les piles, mais c'est une autre considération).

Dans cette architecture :

le reverse-proxy frontal reçoit les 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 proxys exposés par l'agent redirectionio (sur les ports 8080 ou 8081)
les proxys définis dans la configuration de l'agent redirectionio transmettent les requêtes à leurs destinations forward: respectives

Comment puis-je faire évoluer l'agent ?

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

Dans un environnement statique / architecture de serveurs, lancer plusieurs fois l'agent redirectionio est absolument acceptable. Veillez à donner un nom unique à chaque instance, afin de pouvoir la reconnaître ensuite dans l'écran "instances" de l'interface graphique du gestionnaire (et recevoir des notifications si une instance est obsolète).

Dans les environnements dynamiques, il est également parfaitement autorisé de lancer autant d'instances de l'agent que nécessaire, chaque fois que des pics de trafic apparaissent. Afin de définir un nom unique pour chaque instance de l'agent, rappelez-vous que vous pouvez utiliser des variables d'environnement dans la configuration de l'agent.

Utilisation de l'agent redirection.io dans un conteneur docker

Bien sûr, l'agent redirection.io peut être utilisé dans votre environnement docker local ou de production.

Ajoutez un nouveau service redirectionio-agent avec docker-compose :

volumes:
    redirectionio-data: {}

services:
  application:
    # your application service
    
  redirectionio-agent:
    build: services/redirectionio-agent
    ports:
      - "127.0.0.1:8443:443"
      - "127.0.0.1:8080:80"
    volumes:
      - redirectionio-data:/var/lib/redirectionio
    environment:
      - INSTANCE_NAME=${REDIRECTIONIO_INSTANCE_NAME}
      - REDIRECTIONIO_PROJECT_KEY=${REDIRECTIONIO_PROJECT_KEY}

Définissez le service correspondant dans son Dockerfile, dans services/redirectionio-agent/Dockerfile :

FROM alpine:3.17 as alpine

WORKDIR /tmp

RUN apk add --no-cache wget ca-certificates \
    && wget https://packages.redirection.io/dist/stable/2/any/redirectionio-agent-latest_any_amd64.tar.gz \
    && tar -xzvf redirectionio-agent-latest_any_amd64.tar.gz

FROM scratch

# Binary copied from tar
COPY --from=alpine /tmp/redirection-agent/redirectionio-agent /usr/local/bin/redirectionio-agent

# Configuration, can be replaced by your own
COPY etc /etc

# Root SSL Certificates, needed as we do HTTPS requests to our service
COPY --from=alpine /etc/ssl/certs/ca-certificates.crt /etc/ssl/certs/

# Cache storage for rules
VOLUME /var/lib/redirectionio

CMD ["/usr/local/bin/redirectionio-agent"]

De plus, définissez la configuration de redirection.io dans services/redirectionio-agent/etc/redirectionio/agent.yml :

instance_name: "${INSTANCE_NAME}"

proxies:
  -
      listen: 0.0.0.0:80
      forward: http://application:80
      project_key: "${REDIRECTIONIO_PROJECT_KEY}"
  -
      listen: 0.0.0.0:443
      forward: https://application:443
      project_key: "${REDIRECTIONIO_PROJECT_KEY}"
      tls_cert_file: "/etc/ssl/certs/ssl-cert-snakeoil.pem"
      tls_key_file: "/etc/ssl/private/ssl-cert-snakeoil.key"
      allow_invalid_certificates: true
      preserve_host: true

Ce fichier utilise deux variables d'environnement (REDIRECTIONIO_PROJECT_KEY et INSTANCE_NAME) qui sont transmises par docker. Définissez les valeurs correspondantes dans un fichier .env :

REDIRECTIONIO_INSTANCE_NAME=docker dev env
REDIRECTIONIO_PROJECT_KEY=YOUR PROJECT KEY HERE

Comment surveiller l'agent redirection.io

En tant que reverse-proxy, l'agent redirection.io est un logiciel que vous voudrez surveiller attentivement. Il fournit un point de terminaison de surveillance intégré qui expose plusieurs métriques de santé.

Performances attendues

Le reverse-proxy de redirection.io est très performant. Nous ne fournissons pas de chiffres, mais il surpasse largement les serveurs web courants 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.

Cette page a été mise à jour le 30 juin 2025

Vous ne trouvez pas votre réponse ?

Contactez notre support