From fe39ffb8b90ae4e002ed73fe98617cd590abb467 Mon Sep 17 00:00:00 2001 From: Daniel Baumann Date: Sat, 27 Apr 2024 08:33:50 +0200 Subject: Adding upstream version 2.4.56. Signed-off-by: Daniel Baumann --- docs/manual/howto/reverse_proxy.html.fr.utf8 | 381 +++++++++++++++++++++++++++ 1 file changed, 381 insertions(+) create mode 100644 docs/manual/howto/reverse_proxy.html.fr.utf8 (limited to 'docs/manual/howto/reverse_proxy.html.fr.utf8') diff --git a/docs/manual/howto/reverse_proxy.html.fr.utf8 b/docs/manual/howto/reverse_proxy.html.fr.utf8 new file mode 100644 index 0000000..d9d634e --- /dev/null +++ b/docs/manual/howto/reverse_proxy.html.fr.utf8 @@ -0,0 +1,381 @@ + + + + + +Guide de configuration d'un mandataire inverse - Serveur HTTP Apache Version 2.4 + + + + + + + +
<-
+

Guide de configuration d'un mandataire inverse

+
+

Langues Disponibles:  en  | + fr 

+
+ +

En plus de ses fonctions de serveur web "basique", à savoir fournir du + contenu statique et dynamique à l'utilisateur, Apache httpd (comme la + plupart des autres serveurs web) peut aussi assurer les fonctions de serveur + mandataire inverse, connu aussi sous le nom de serveur "passerelle".

+ +

Dans un tel scénario, httpd ne génère et n'héberge pas lui-même les + données, le contenu étant en général obtenu à partir d'un ou plusieurs serveurs + d'arrière-plan qui n'ont normalement aucune connexion directe avec le réseau + externe. Lorsque httpd reçoit une requête en provenance d'un client, la + requête proprement dite est mandatée vers un de ces serveurs + d'arrière-plan qui traite la requête, génère le contenu et l'envoie à httpd, + ce dernier générant la véritable réponse HTTP à destination du client.

+ +

De nombreuses raisons peuvent vous motiver à utiliser cette + fonctionnalité, mais elles sont souvent du domaine de la sécurité, de + la haute disponibilité, de la répartition de charge et de + l'authentification/autorisation centralisée. Il est alors indispensable que + l'organisation, la conception et l'architecture de l'infrastructure + d'arrière-plan (les serveurs qui traitent au sens propre les requêtes) soient + isolées et protégées de l'extérieur ; vu du client, le serveur mandataire + inverse est le seul serveur accessible pouvant lui fournir du + contenu.

+ +

Voici un exemple typique d'implémentation de cette fonctionnalité :

+

reverse-proxy-arch

+ +
+ +
top
+
top
+
+

Mandatement inverse simple

+ + +

+ La directive ProxyPass permet de + rediriger les requêtes entrantes vers un serveur d'arrière-plan (ou un + cluster de serveurs plus connu sous le nom de groupe + Balancer). Dans cet exemple le plus simple, toutes les + requêtes ("/") sont redirigées vers un serveur d'arrière-plan + unique : +

+ +
ProxyPass "/"  "http://www.example.com/"
+ + +

+ Pour être sur que cette redirection soit effectuée et que les en-têtes + Location: générés par le serveur d'arrière-plan soient + modifiés pour pointer vers le mandataire inverse, et non vers le serveur + d'arrière-plan, la directive ProxyPassReverse est souvent requise : +

+ +
ProxyPass "/"  "http://www.example.com/"
+ProxyPassReverse "/"  "http://www.example.com/"
+ + +

Seules des URIs spécifiques peuvent être mandatées, comme le montre + l'exemple suivant :

+ +
ProxyPass "/images"  "http://www.example.com/"
+ProxyPassReverse "/images"  "http://www.example.com/"
+ + +

Dans l'exemple précédent, si le chemin d'une requête commence par + /images, elle sera redirigée vers le serveur d'arrière-plan + spécifié ; dans le cas contraire, elle sera traitée localement. +

+
top
+
+

Clusters et Balancers

+ + +

+ Utiliser un serveur d'arrière-plan unique n'est cependant pas une solution + idéale car ce dernier peut devenir indisponible ou surchargé, et le + mandatement inverse vers ce serveur ne présente alors plus aucun avantage. + La solution réside dans la définition d'un groupe de serveurs + d'arrière-plan qui vont se partager le traitement des requêtes via un + mécanisme de répartition de charge et de gestion des indisponibilités pris + en charge par le mandataire. Ce groupe de répartition est plus connu sous le nom de + cluster, mais dans la terminologie d'Apache httpd, on utilise + plutôt le terme de balancer. Un balancer se définit en + utilisant les directives <Proxy> et BalancerMember comme suit : +

+ +
<Proxy balancer://myset>
+    BalancerMember http://www2.example.com:8080
+    BalancerMember http://www3.example.com:8080
+    ProxySet lbmethod=bytraffic
+</Proxy>
+
+ProxyPass "/images/"  "balancer://myset/"
+ProxyPassReverse "/images/"  "balancer://myset/"
+ + +

+ Le protocole balancer:// indique à httpd que l'on souhaite + créer un balancer nommé myset. Ce balancer comporte deux serveurs + d'arrière-plan référencés dans la terminologie httpd sous le nom de + BalancerMembers. Avec cet exemple, toute requête dont le chemin + commence par /images sera mandatée vers un des deux + serveurs d'arrière-plan. La directive ProxySet définit ici pour le balancer + myset un algorithme de + répartition de charge basé sur le trafic entrées/sorties. +

+ +

Remarque

+

+ Les BalancerMembers sont aussi souvent référencés sous le terme + workers. +

+
+ +
top
+
+

Configuration du Balancer et des BalancerMembers

+ + +

+ Vous pouvez configurer de manière détaillée les balancers et + workers via les nombreux paramètres de la directive ProxyPass. Par exemple, si vous souhaitez + que http://www3.example.com:8080 traite avec un facteur 3 le + trafic avec un timeout d'une seconde, utilisez la configuration suivante : +

+ +
<Proxy balancer://myset>
+    BalancerMember http://www2.example.com:8080
+    BalancerMember http://www3.example.com:8080 loadfactor=3 timeout=1
+    ProxySet lbmethod=bytraffic
+</Proxy>
+
+ProxyPass "/images"  "balancer://myset/"
+ProxyPassReverse "/images"  "balancer://myset/"
+ + +
top
+
+

Gestion des indisponibilités (Failover)

+ + +

+ Vous pouvez aussi définir finement des scénarios pour les cas + d'indisponibilité d'un ou plusieurs serveurs d'arrière-plan en spécifiant + quels serveurs doivent alors prendre le relai. Dans l'exemple suivant, + trois scénarios sont envisagés : +

+
    +
  1. + http://spare1.example.com:8080 et + http://spare2.example.com:8080 ne sont sollicités que si + http://www2.example.com:8080 ou + http://www3.example.com:8080 est indisponible (un serveur + de remplacement sera utilisé à la place d'un membre indisponible du même + jeu de serveurs cibles). +
  2. +
  3. + http://hstandby.example.com:8080 n'est sollicité que si + tous les autres serveurs cibles du jeu de serveurs 0 sont + indisponibles. +
  4. +
  5. + Les serveurs http://bkup1.example.com:8080 et + http://bkup2.example.com:8080 du jeu 1 ne seront sollicités que si + tous les serveurs du jeu 0, tous les serveurs de + remplacement et tous les serveurs de standby sont indisponibles. +
  6. +
+

+ Il est ainsi possible de définir un ou plusieurs serveurs de remplacement + ou de standby pour chaque jeu de serveurs du répartiteur de charge. +

+ +
<Proxy balancer://myset>
+    BalancerMember http://www2.example.com:8080
+    BalancerMember http://www3.example.com:8080 loadfactor=3 timeout=1
+    BalancerMember http://spare1.example.com:8080 status=+R
+    BalancerMember http://spare2.example.com:8080 status=+R
+    BalancerMember http://hstandby.example.com:8080 status=+H
+    BalancerMember http://bkup1.example.com:8080 lbset=1
+    BalancerMember http://bkup2.example.com:8080 lbset=1
+    ProxySet lbmethod=byrequests
+</Proxy>
+
+ProxyPass "/images/"  "balancer://myset/"
+ProxyPassReverse "/images/"  "balancer://myset/"
+ + +

+ Les serveurs de remplacement à chaud remplacent les serveurs indisponibles + du même jeu de serveurs du répartiteur de charge. Un serveur est + considéré comme indisponible s'il est en maintenance, arrêté ou en erreur. + Les serveurs de standby à chaud sont utilisés si tous les serveurs et + serveurs de remplacement du jeu de serveurs du répartiteur de charge sont + indisponibles. Les jeux de serveurs du répartiteur de charge (avec leurs + serveurs de standby et de remplacement à chaud respectifs) sont toujours + sollicités dans l'ordre du plus bas lbset vers le plus haut. +

+ +
top
+
+

Gestion du répartiteur de charge

+ + +

+ L'application balancer-manager fournie avec le mandataire inverse + d'Apache httpd en est un des outils les plus utiles. Comme + mod_status, balancer-manager affiche la + configuration et l'activité actuelles des balancers actifs. L'affichage de + ces informations n'est cependant pas sa seule fonction ; il permet aussi de + modifier la plupart d'entre elles et même d'ajouter des membres au groupe + de répartition de charge en temps réel. Pour activer ces fonctionnalités, + vous devez ajouter les lignes suivantes à votre fichier de configuration : +

+ +
<Location "/balancer-manager">
+    SetHandler balancer-manager
+    Require host localhost
+</Location>
+ + +

Avertissement

+

N'activez le balancer-manager que si vous avez déjà sécurisé votre serveur. + Assurez-vous en particulier que l'accès à l'URL soit fortement restreint.

+
+ +

+ Lorsque vous accédez au serveur mandataire avec une adresse du style + http://rproxy.example.com/balancer-manager/, la page suivante + s'affiche : +

+

balancer-manager page

+ +

+ Ce formulaire permet à l'administrateur de modifier certains paramètres, + de désactiver ou d'ajouter certains serveurs d'arrière-plan, et de + modifier les règles de répartition de charge. Par exemple, si on clique + sur le répartiteur, la page suivante s'affiche : +

+

balancer-manager page

+ +

+ Si on clique sur un membre du groupe de répartition de charge, la page + suivante s'affiche : +

+

balancer-manager page

+ +

+ Si vous souhaitez que ces modifications soient conservées après un + redémarrage du serveur, assurez-vous que la directive BalancerPersist soit définie à On. +

+ +
top
+
+

Vérification dynamique du bon fonctionnement d'un serveur + d'arrière-plan

+ + +

+ Avant que le mandataire httpd ne fasse appel à un serveur d'arrière-plan, il + peut "tester" si ce dernier est disponible en définissant le + paramètre ping de ce serveur via la directive ProxyPass. Cependant, il est souvent plus + judicieux de vérifier le bon fonctionnement d'un serveur hors + bande et de manière dynamique via le module + mod_proxy_hcheck d'Apache httpd. +

+ +
top
+
+

Drapeaux d'état d'un membre du groupe de répartition de charge

+ + +

+ balancer-manager permet d'afficher et de modifier l'état d'un + membre du groupe de répartition de charge. Les différents états et leurs + significations sont les suivants : +

+ + + + + + + + + + + + +
DrapeauSigleDescription
 OkLe serveur est disponible
 InitLe serveur a été initialisé
DDisLe serveur est + désactivé et n'accepte aucune requête ; il sera retesté automatiquement.
SStopLe serveur a été + arrêté par l'administrateur ; il n'accepte aucune requête et il ne sera + pas retesté automatiquement.
IIgnLes erreurs + concernant ce serveur sont ignorées et il sera donc toujours considéré + comme disponible.
RSparLe serveur cible sert de remplaçant à + chaud. Lorsqu'un serveur cible avec un lbset donné est inutilisable + (maintenance, arrêt, en erreur, etc...), un serveur de remplacement à + chaud libre de même lbset sera utilisé à sa place. Les remplaçants à + chaud permettent de s'assurer qu'un nombre déterminé de serveurs cibles + sera toujours disponible pour un répartiteur de charge.
HStbyLe serveur est en + mode hot-standby et ne sera donc utilisé que si aucun autre serveur ou + serveur de remplacement n'est disponible dans le jeu de serveurs du + répartiteur de charge.
EErrLe serveur est en + erreur, en général suite à un test préalable à une requête ; aucune + requête ne lui sera soumise, mais il sera retesté en fonction de la + valeur de son paramètre retry.
NDrnLe serveur est en + mode drain ; il n'acceptera de requêtes que dans le cadre des sessions + persistantes qui lui sont réservées et ignorera toutes les autres.
CHcFlLe serveur a échoué + au test dynamique de bon fonctionnement et ne sera utilisé que lorsqu'il + aura réussi un test ultérieur.
+
+
+

Langues Disponibles:  en  | + fr 

+
top

Commentaires

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Libera.chat, or sent to our mailing lists.
+
+ \ No newline at end of file -- cgit v1.2.3