[Apache] Créer un reverse-proxy

Parfois, le besoin et le développement font que l'on se retrouve avec plusieurs serveurs d'application installés sur plusieurs machines et que l'on souhaite que les applications tournant sur ceux-ci soient accessibles via un unique point d'entrée.
Ce point d'entrée se traduit souvent par un nom de domaine auquel est raccroché une unique adresse IP. Il est tout a fait possible de desservir plusieurs serveurs d'application à partir d'un seul serveur Apache httpd qui servira de point d'entrée.

Ce seul serveur permettra de plus d'authoriser les accès aux applications par htaccess.

Différents modes de reverse proxy
Mise en situation
Reverse-Proxy par réécriture d'URL
Reverse-Proxy avec le mod_proxy

Différents modes de reverse proxy :

Il est possible de faire du reverse proxy de 2 manières possibles avec httpd :

par réécriture d'URL
avec le module Proxy

L'avantage de la réécriture d'URL est que le module correspondant est bien souvent intégré de base avec httpd et par conséquent facile à mettre en place.
En revanche, le module Proxy n'est pas toujours installé et par conséquent il faut l'ajouter. Cce module est totalement dédié à cette fonctionnalité et donc plus optimale.

J'ai été amené à utiliser les 2 en même temps par la force des choses.
En effet, dans ma société nous disposons d'applications écrites en Rails et d'autres en Java. Étrangement, le reverse proxy fait par réécriture d'URL fonctionne bien pour les backoffices Rails mais pas avec ceux écrits en Java et le module Proxy fonctionne bien avec ces derniers mais pas avec les versions Rails...

Celà dit, ça m'a permis de voir comment mettre en place ces 2 techniques et de les faire cohabiter sans problème.

Mise en situation :

Dans le cadre de la mise en reverse-proxy que j'ai eu à traiter, je disposais de 5 backoffices en Rails et de 2 backoffices en Java.
De plus, parce que notre équipe n'est pas nécessairement dans les locaux de la société, il faut que tout le monde puisse accéder à tous les backoffices. Par mesure de sécurité, les personnes n'accédant pas aux applications depuis le réseau interne doivent s'identifier via htaccess.

Afin de pouvoir remplir chacune des conditions (plusieurs backoffices de natures différentes, accès authentifiés suivant le réseau d'accès), j'ai utilisé les VirtualHost de httpd, chacun d'eux pointant vers la même "application" : une simple page PHP de portail d'accès.
Chaque application de backoffice répond par un sous-domaine.

Un extrait de la page portail index.php :

<html>
<head>
<title>Pavnay's backoffice portal</title>
<link href="/stylesheets/mycss.css" media="screen" rel="Stylesheet" type="text/css" />
</head>
<body>
    
<a href="/" title="Back-Office"><img src="/images/pavnay.gif" width="230" height="51" alt="Pavnay" /></a>                    
<div id="overDiv" style="position:absolute; visibility:hidden; z-index:1000;"></div>
    <div>    
        <div>
        
        <ul class="Menu" />
        <div id="session-navhelp" />        
    </div>        
   </div>
   <div id="page">
    <div id="tips"><br /></div>
            <div id="content" align="center">
                <br />
                <p><strong>Access to</strong></p>
                <br />

                <ol>     
                    <li> <a href="http://app1.<?php echo $_SERVER['HTTP_HOST']; ?>">Application 1<a><br />
                    <li> <a href="http://app2.<?php echo $_SERVER['HTTP_HOST']; ?>">Application 2<a><br />
                    <li> <a href="http://app3.<?php echo $_SERVER['HTTP_HOST']; ?>">Application 3<a><br />
                    <li> <a href="http://app4.<?php echo $_SERVER['HTTP_HOST']; ?>">Application 4<a><br />

                </ol>

           </div>
    </div>
</body>
</html>

Bien que simple, cette page permet de gérer le portail pour l'intra et l'extra net... Ainsi le portail répond par exemple à l'adresse http://pavnay.fr et donc les adresses des backoffices sont de la forme http://app1.pavnay.fr.
Maintenant il ne reste plus qu'à créer les VirtualHost avec les configurations de reverse-proxy.

Reverse-Proxy par réécriture d'URL :

Le reverse-proxy par réécriture d'URL est assez facile à mettre en place.
Pour que celui-ci fonctionne, il faut que httpd dispose du module de réécriture : mod_rewrite.

RewriteEngine On    
RewriteLogLevel 100    
RewriteLog "/usr/local/apache2/logs/rewrite.log"    
RewriteMap mapping txt:/usr/local/apache2/conf/mapping.txt    
RewriteCond ${mapping:%{SERVER_NAME}|NOT-FOUND} !=NOT-FOUND    
RewriteRule ^/(.*)$  http://${mapping:%{SERVER_NAME}}/$1 [QSA,NC,P,L]

Quelques explications :

RewriteEngine On permet d'activer le module de réécriture d'URL
RewriteMap est la déclaration du fichier de mapping
RewriteCond permet de faire un mapping entre le domaine appelé et l'application associée
RewriteRule est la redirection internet entre le client et l'application cible. Ce qui permet du reverse-proxy est le flag P en fin de ligne

Dans cet exemple, le mapping entre l'URL saisie et l'application souhaitée est fait dans le fichier /usr/local/apache2/conf/mapping.txt :

app1.pavnay.fr server.pavnay.local:3001 
app2.pavnay.fr server.pavnay.local:3002  
app3.pavnay.fr 192.168.1.100:80

Ici par exemple, l'URL public app1.pavnay.fr est réécrite localement pour pointer une application hébergée sur un serveur (server.pavnay.local) et tournant sur le port 3001.

La configuration complète du VirtualHost avec le reverse-proxy par réécriture d'URL :

 <VirtualHost *:80>
   ServerAdmin postmaster@pavnay.fr
   ServerName pavnay.fr
   ServerAlias *.pavnay.fr
   RewriteEngine On
   RewriteLogLevel 100
   RewriteLog "/usr/local/apache2/logs/rewrite.log"
   RewriteMap mapping txt:/usr/local/apache2/conf/mapping.txt
   RewriteCond ${mapping:%{SERVER_NAME}|NOT-FOUND} !=NOT-FOUND
   RewriteRule ^/(.*)$  http://${mapping:%{SERVER_NAME}}/$1 [QSA,NC,P,L]
   DocumentRoot "/usr/local/webapps/portal"
   <Directory "/usr/local/webapps/portal">
         Options Indexes
         AllowOverride None
         Order allow,deny
         Allow from all
   </Directory>
</VirtualHost>

Reverse-Proxy avec le mod_proxy

Le module mod_proxy est la voie "naturelle" du reverse-proxy.
Il se met en place facilement mais nécessite de le compiler en même temps que le serveur httpd ou bien de le linker séparément.

 <VirtualHost *:80>
    ServerName app4.pavnay.fr
    ErrorLog "logs/app4-error_log"
    CustomLog "logs/app4-access_log" common
    ProxyRequests Off
    ProxyPass / http://app4.pavnay.local/
    ProxyPassReverse / http://app4.pavnay.local/
</VirtualHost>

Quelques explication :

ProxyRequest Off en fait c'est la valeur par défaut mais cela n'empêche pas ProxyPass de fonctionner
ProxyPass permet de mapper un chemin (URI) avec une URL (ici / avec l'adresse de l'application distante locale)
ProxyPassReverse permet de gérer le header Location des réponses de redirection potentiellement envoyées par l'application distante locale

Et voilà, il n'y a rien de plus simple...

Encore une fois, pour une raison que j'ignore, pour le moment, la manière de mettre en place le reverse-proxy dépend des applications distantes.
Parce que j'avais besoin des deux manières de faire, il a fallu que je crée un VirtualHost générique avec la réécriture d'URL et plusieurs VirtualHost pour les applications pour lesquelles la réécriture ne fonctionnait pas (un VirtualHost par application).