Configuration du backend

Lorsqu'une requête est acceptée par l'agent redirection.io, elle est transmise à un serveur backend. Le serveur backend peut être n'importe quel serveur capable de gérer des requêtes HTTP, tel qu'un serveur web, un serveur d'application, un load balancer, un serveur distant, etc. Le serveur backend peut s'exécuter sur la même machine que l'agent, ou sur une machine différente.

Définir l'adresse de forward

La clé de configuration forward vous permet de spécifier l'adresse du serveur backend auquel les requêtes doivent être transmises. L'adresse peut être spécifiée sous la forme host:port, où host est le hostname ou l'adresse IP du serveur backend, et port est le port sur lequel le serveur backend écoute les requêtes entrantes.

Par exemple, la configuration suivante transmettra les requêtes à un serveur backend s'exécutant sur 127.0.0.1:8080 :

instance:
    name: 'Example instance'
reverse_proxy:
    listen:
        - 'tcp://0.0.0.0:80'
    forward:
        address: '127.0.0.1:8080'
    agent:
        project_key: my-project-key

Forward vers un backend TLS

Si l'agent s'exécute devant un serveur backend configuré pour accepter les requêtes HTTPS, vous pouvez configurer l'agent pour transmettre les requêtes au backend en utilisant TLS. Pour ce faire, vous devez spécifier l'option tls dans la configuration forward. Par exemple :

instance:
    name: 'Example instance'
reverse_proxy:
    listen:
        - 'tcp://0.0.0.0:80'
    forward:
        address: 'backend:4443'
        tls:
            sni: example.com
            allow_invalid_certificates: false
    agent:
        project_key: my-project-key

Bien entendu, dans ce cas, l'adresse de forward doit cibler un port configuré pour accepter les connexions TLS.

La directive sni est facultative, et elle vous permet de spécifier le hostname SNI à utiliser lors de la connexion au serveur backend. Si elle n'est pas spécifiée, l'agent utilisera la partie host de l'adresse de forward comme hostname SNI.

L'option allow_invalid_certificates est également facultative, et elle vous permet de spécifier s'il faut ou non autoriser les certificats SSL invalides lors de la connexion au serveur backend. Cela peut être utile si vous utilisez des certificats auto-signés à des fins de test, ou si vous avez un serveur backend avec un certificat SSL qui n'est pas valdie du point de vue de l'agent.

Support d'IPV6

Lorsque l'adresse de forward est définie comme un hostname (par ex. my-backend-server.com:8080), l'agent résoudra automatiquement le hostname en une adresse IP. Par défaut, cette résolution ne retourne que des adresses IPV4, mais vous pouvez configurer l'agent pour accepter également les adresses IPV6 en définissant l'option allow_ipv6 à true dans la configuration forward. Par exemple :

instance:
    name: 'Example instance'
reverse_proxy:
    listen:
        - 'tcp://0.0.0.0:80'
    forward:
        address: 'backend:8080'
        allow_ipv6: true
    agent:
        project_key: my-project-key

Connexions persistantes vers le backend

L'agent redirection.io supporte les connexions persistantes vers le serveur backend, ce qui peut améliorer les performances de traitement des requêtes en réutilisant la même connexion pour plusieurs requêtes successives. Ceci est particulièrement utile si le serveur backend s'exécute sur la même machine que l'agent, ou s'il s'exécute sur un réseau rapide.

Pour activer les connexions persistantes vers le backend, vous pouvez activer l'option keep_alive à true dans la configuration forward. Par exemple :

instance:
    name: 'Example instance'
reverse_proxy:
    listen:
        - 'tcp://0.0.0.0:80'
    forward:
        address: 'backend:8080'
        keep_alive: true
    agent:
        project_key: my-project-key

Par défaut, l'option keep_alive est définie sur false, ce qui signifie que l'agent fermera la connexion au serveur backend après chaque requête. Si vous activez l'option keep_alive, l'agent gardera la connexion au serveur backend ouverte pendant un certain temps, et il réutilisera la même connexion pour plusieurs requêtes.

Le timeout et le nombre maximum de requêtes pour les connexions persistantes peuvent être configurés en utilisant la syntaxe détaillée de keep_alive, par exemple :

instance:
    name: 'Example instance'
reverse_proxy:
    listen:
        - 'tcp://0.0.0.0:80'
    forward:
        address: 'backend:8080'
        keep_alive:
            idle_timeout: 30s
            born_timeout: 1h
            max_requests: 10000
    agent:
        project_key: my-project-key

Par défaut :  * le idle_timeout est défini sur 5s, ce qui signifie que l'agent fermera la connexion au serveur backend s'il est inactif pendant plus de 5 secondes  * le born_timeout est défini sur 3600s, ce qui signifie que l'agent fermera la connexion au serveur backend s'il est ouvert depuis plus d'une heure, quelle que soit l'activité sur la connexion  * l'option max_requests est définie sur 0 par défaut, ce qui signifie qu'il n'y a pas de limite au nombre de requêtes pouvant être gérées par la même connexion.

Configuration des timeouts

La configuration de l'agent redirection.io concernant les timeouts est très flexible, et vous permet d'ajuster précisément le comportement de l'agent en cas de backends lents ou ne répondant pas, ou en cas de requêtes de longue durée.

Les options de timeout disponibles concernant la gestion des requêtes se trouvent sous la clé de configuration timeout, et elles vous permettent de spécifier le temps maximum d'attente pour les différentes étapes du processus de gestion des requêtes.

instance:
    name: 'Example instance'
reverse_proxy:
    listen:
        - 'tcp://0.0.0.0:80'
    forward:
        address: 'backend:8080'
    timeout:
        resolve: 100ms
        connect: 100ms
        tls_handshake: 100ms
        request: 1s
        response: 1s
    agent:
        project_key: my-project-key

Voici les options de timeout disponibles :

 * resolve : le temps maximum d'attente pour la résolution du hostname du serveur backend (si l'adresse de forward est définie sous la forme d'un hostname)  * connect : le temps maximum d'attente pour que la connexion au serveur backend soit établie  * tls_handshake : le temps maximum d'attente pour que le handshake TLS soit terminé (lors de la connexion à un serveur backend TLS)  * request : le temps maximum d'attente pour que la requête soit envoyée au serveur backend. Le timeout est réinitialisé chaque fois que de nouvelles données sont envoyées.  * response : le temps maximum d'attente pour que la réponse soit reçue du serveur backend. Le timeout est réinitialisé chaque fois que de nouvelles données sont reçues.

Si l'un de ces timeouts est atteint, l'agent considérera que le serveur backend ne répond pas, et il renverra une réponse d'erreur au client. La réponse d'erreur aura un code d'état 503 Service Unavailable, et inclura un message d'erreur dans le corps de la réponse pour préciser quel timeout a été atteint.

Utiliser le système de fichiers local en tant que backend

L'agent redirection.io supporte également l'utilisation du système de fichiers local comme backend, ce qui peut être utile pour servir des fichiers statiques, tels que des images, des vidéos, des documents, etc. Pour ce faire, vous devez spécifier l'option directory dans la configuration forward, et fournir le chemin vers le répertoire qui contient les fichiers à servir. Par exemple :

instance:
    name: 'My Instance'
reverse_proxy:
    listen:
        - 'tcp://0.0.0.0:80'
    forward:
        directory: /var/www/media
    agent:
        project_key: my-project-key

Lors de l'utilisation du système de fichiers local comme backend, l'agent servira les fichiers tels quels, sans aucun traitement. Si la ressource n'est pas trouvée dans le répertoire spécifié, l'agent renverra une réponse d'erreur 404 Not Found (qui peut être personnalisée en créant une règle redirection.io avec le déclencheur "backend status code" défini sur 404).