Comment utiliser Apache en tant que proxy inverse avec mod_proxy sur Debian 8

introduction

Un proxy inverse est un type de serveur proxy qui accepte les requêtes HTTP (S) et les distribue de manière transparente à un ou plusieurs serveurs principaux. Les proxys inversés sont utiles car de nombreuses applications Web modernes traitent les demandes HTTP entrantes à l’aide de serveurs d’applications dorsaux auxquels les utilisateurs ne doivent pas accéder directement et ne prennent souvent en charge que des fonctionnalités HTTP rudimentaires.

Vous pouvez utiliser un proxy inverse pour empêcher l’accès direct à ces serveurs d’applications sous-jacents. Ils peuvent également être utilisés pour répartir la charge des demandes entrantes vers plusieurs serveurs d’applications différents, augmentant ainsi les performances à l’échelle et offrant une sécurité à l’échec. Ils peuvent combler les lacunes avec des fonctionnalités que les serveurs d’applications n’offrent pas, telles que la mise en cache, la compression ou le cryptage SSL.

Dans ce tutoriel, vous allez configurer Apache en tant que proxy inverse de base à l’aide de l’extension + mod_proxy + pour rediriger les connexions entrantes vers un ou plusieurs serveurs dorsaux fonctionnant sur le même réseau. Ce tutoriel utilise un simple backend écrit avec le framework Web avec Flask, mais vous pouvez utiliser n’importe quel serveur principal que vous préférez.

Conditions préalables

Pour suivre ce tutoriel, vous aurez besoin de:

Étape 1 - Activation des modules Apache nécessaires

Apache contient de nombreux modules disponibles, mais non activés dans une nouvelle installation. Tout d’abord, nous devons activer ceux que nous utiliserons dans ce tutoriel.

Les modules dont nous avons besoin sont + mod_proxy + lui-même et plusieurs de ses modules additionnels, qui étendent ses fonctionnalités pour prendre en charge différents protocoles réseau. Plus précisément, nous allons utiliser:

  • + mod_proxy +, le module Apache principal du module proxy pour la redirection des connexions; cela permet à Apache d’agir en tant que passerelle vers les serveurs d’applications sous-jacents.

  • + mod_proxy_http +, qui ajoute le support pour le proxy des connexions HTTP.

  • + mod_proxy_balancer + et + mod_lbmethod_byrequests +, qui ajoutent des fonctionnalités d’équilibrage de la charge pour plusieurs serveurs dorsaux.

Pour activer ces quatre modules, exécutez les commandes suivantes successivement.

sudo a2enmod proxy
sudo a2enmod proxy_http
sudo a2enmod proxy_balancer
sudo a2enmod lbmethod_byrequests

Pour appliquer ces modifications, redémarrez Apache.

sudo systemctl restart apache2

Apache est maintenant prêt à agir en tant que proxy inverse pour les requêtes HTTP. Dans la prochaine étape (facultative), nous allons créer deux serveurs principaux très basiques. Cela nous aidera à vérifier si la configuration fonctionne correctement, mais si vous avez déjà votre propre application (s) dorsale (s), vous pouvez passer à l’étape 3.

Étape 2 - Création de serveurs de test backend

L’exécution de serveurs dorsaux simples constitue un moyen simple de vérifier si votre configuration Apache fonctionne correctement. Ici, nous allons créer deux serveurs de test qui répondent aux requêtes HTTP en imprimant une ligne de texte. Un serveur dira * Hello world! * Et l’autre dira * Howdy world! *.

Flask est un microframework Python pour la construction d’applications Web. Nous utilisons Flask pour créer les serveurs de test, car une application de base ne nécessite que quelques lignes de code. Vous n’avez pas besoin de connaître Python pour les configurer, mais si vous souhaitez apprendre, vous pouvez consulter cette introduction à Python .

Mettez à jour la liste des packages en premier.

sudo apt-get update

Ensuite, installez Pip, le gestionnaire de packages Python recommandé.

sudo apt-get -y install python3-pip

Utilisez Pip pour installer Flask.

sudo pip3 install flask

Maintenant que tous les composants requis sont installés, commencez par créer un nouveau fichier qui contiendra le code du premier serveur principal dans le répertoire de base de l’utilisateur actuel.

nano ~/backend1.py

Copiez le code suivant dans le fichier, puis enregistrez et fermez-le.

~ / backend1.py

from flask import Flask
app = Flask(__name__)

@app.route('/')
def home():
   return 'Hello world!'

Les deux premières lignes initialisent le framework Flask. Il existe une fonction, + home () +, qui renvoie une ligne de texte (+ Hello world! +). La ligne [email protected] ('/') + située au-dessus de la définition de la fonction + home () + indique à Flask d’utiliser la valeur de retour home + () + en réponse aux requêtes HTTP adressées à l’adresse URL de racine «+ / +» de l’application.

Le deuxième serveur principal est identique au premier, mis à part le retour à une ligne de texte différente. Commencez donc par dupliquer le premier fichier.

cp ~/backend1.py ~/backend2.py

Ouvrez le fichier récemment copié.

nano ~/backend2.py

Remplacez le message par * Hello world! * Par * Howdy world! *, Puis enregistrez et fermez le fichier.

~ / backend2.py

from flask import Flask
app = Flask(__name__)

@app.route('/')
def home():
   return ''

Utilisez la commande suivante pour démarrer le premier serveur d’arrière-plan sur le port + 8080 +. Cela redirige également la sortie de Flask vers + / dev / null + car cela nuirait plus tard la sortie de la console.

FLASK_APP=~/backend1.py flask run --port=8080 >/dev/null 2>&1 &

Nous procédons ici à la commande + flask ​​en définissant la variable d’environnement` + FLASK_APP` sur la même ligne. Les variables d’environnement constituent un moyen pratique de transmettre des informations aux processus générés à partir du shell. Pour en savoir plus sur les variables d’environnement, consultez la page How To Lire et définir les variables d’environnement et de shell sur un VPS Linux.

Dans ce cas, l’utilisation d’une variable d’environnement permet de s’assurer que le paramètre s’applique uniquement à la commande en cours d’exécution et ne restera pas disponible par la suite, car nous allons transmettre un autre nom de fichier de la même manière pour indiquer à la commande + flask + de démarrer le deuxième serveur.

De même, utilisez cette commande pour démarrer le deuxième serveur sur le port + 8081 +. Notez la valeur différente pour la variable d’environnement + FLASK_APP.

FLASK_APP=~/backend2.py flask run --port=8081 >/dev/null 2>&1 &

Vous pouvez vérifier que les deux serveurs fonctionnent en utilisant + curl. Testez le premier serveur:

curl http://127.0.0.1:8080/

Ceci affichera * Hello world! * Dans le terminal. Testez le deuxième serveur:

curl http://127.0.0.1:8081/

Cela produira * Howdy world! * À la place.

Dans l’étape suivante, nous modifierons le fichier de configuration d’Apache pour permettre son utilisation en tant que proxy inverse.

Étape 3 - Modification de la configuration par défaut pour activer le proxy inverse

Dans cette section, nous allons configurer l’hôte virtuel Apache par défaut pour qu’il serve de proxy inverse pour un serveur dorsal unique ou un tableau de serveurs dorsaux à charge équilibrée.

Ouvrez le fichier de configuration Apache par défaut en utilisant + nano + ou votre éditeur de texte favori.

sudo nano /etc/apache2/sites-available/000-default.conf

Dans ce fichier, vous trouverez le bloc + <VirtualHost *: 80> + commençant à la première ligne. Le premier exemple ci-dessous explique comment configurer ce bloc pour inverser le proxy pour un seul serveur dorsal, et le second configure un proxy inverse à charge équilibrée pour plusieurs serveurs dorsaux.

Exemple 1 - Proxy inverse d’un serveur dorsal unique

Remplacez tout le contenu du bloc + VirtualHost + par ce qui suit, afin que votre fichier de configuration ressemble à ceci:

/etc/apache2/sites-available/000-default.conf

<VirtualHost *:80>




</VirtualHost>

Si vous avez suivi l’exemple des serveurs à l’étape 2, utilisez +127.0.0.1: 8080 + comme indiqué dans le bloc ci-dessus. Si vous avez vos propres serveurs d’applications, utilisez plutôt leurs adresses.

Il y a trois directives ici:

  • + ProxyPreserveHost + permet à Apache de transmettre l’en-tête + Host + d’origine au serveur principal. Ceci est utile car il informe le serveur principal de l’adresse utilisée pour accéder à l’application.

  • + ProxyPass + est la directive de configuration principale du proxy. Dans ce cas, il est spécifié que tout ce qui se trouve sous l’URL racine (+ / +) doit être mappé sur le serveur principal à l’adresse donnée. Par exemple, si Apache obtient une demande pour + + exemple + , il se connectera à + http: /// exemple + `et renverra la réponse au client d’origine.

  • + ProxyPassReverse + devrait avoir la même configuration que + ProxyPass +. Il demande à Apache de modifier les en-têtes de réponse du serveur principal. Cela garantit que si le serveur back-end retourne un en-tête de redirection d’emplacement, le navigateur du client sera redirigé vers l’adresse proxy et non l’adresse du serveur back-end, ce qui ne fonctionnerait pas comme prévu.

Pour appliquer ces modifications, redémarrez Apache.

sudo systemctl restart apache2

Maintenant, si vous accédez à + ​​http: // + dans un navigateur Web, vous verrez la réponse de votre serveur principal au lieu de la page d’accueil Apache standard. Si vous avez suivi l’étape 2, cela signifie que vous verrez * Hello world! *.

Exemple 2 - Equilibrage de la charge sur plusieurs serveurs principaux

Si vous avez plusieurs serveurs principaux, un bon moyen de répartir le trafic entre eux lors de l’utilisation de serveurs mandataires consiste à utiliser les fonctions d’équilibrage de charge de + mod_proxy +.

Remplacez tout le contenu du bloc + VirtualHost + par ce qui suit, afin que votre fichier de configuration ressemble à ceci:

/etc/apache2/sites-available/000-default.conf

<VirtualHost *:80>









</VirtualHost>

La configuration est similaire à la précédente, mais au lieu de spécifier directement un serveur principal, nous avons utilisé un bloc + Proxy + supplémentaire pour définir plusieurs serveurs. Le bloc s’appelle + balancer: // + (le nom peut être modifié librement) et consiste en un ou plusieurs + BalancerMember + s, qui spécifient les adresses de serveur principal sous-jacentes. Les directives + ProxyPass + et + ProxyPassReverse + utilisent le pool d’équilibreur de charge nommé + mycluster + au lieu d’un serveur spécifique.

Si vous avez suivi l’exemple des serveurs à l’étape 2, utilisez +127.0.0.1: 8080 + et +127.0.0.1: 8081 + pour les directives + BalancerMember +, comme indiqué dans le bloc ci-dessus. Si vous avez vos propres serveurs d’applications, utilisez plutôt leurs adresses.

Pour appliquer ces modifications, redémarrez Apache.

sudo systemctl restart apache2

Si vous accédez à + ​​http: // + depuis un navigateur Web, vous verrez les réponses de vos serveurs principaux au lieu de la page Apache standard. Si vous avez suivi l’étape 2, l’actualisation répétée de la page doit afficher * Hello world! * Et * Howdy world! *, Ce qui signifie que le proxy inverse fonctionne et répartit la charge entre les deux serveurs.

Conclusion

Vous savez maintenant comment configurer Apache en tant que proxy inverse sur un ou plusieurs serveurs d’applications sous-jacents. + mod_proxy + peut être utilisé efficacement pour configurer le proxy inverse sur des serveurs d’applications écrits dans un vaste éventail de langages et de technologies, tels que Python et Django ou Ruby et Ruby on Rails. Il peut également être utilisé pour équilibrer le trafic entre plusieurs serveurs principaux pour des sites très fréquentés ou pour offrir une haute disponibilité via plusieurs serveurs, ou pour fournir une prise en charge SSL sécurisée à des serveurs dorsaux ne prenant pas SSL en charge de manière native.

Alors que + mod_proxy + avec + mod_proxy_http + est peut-être la combinaison de modules la plus couramment utilisée, il en existe plusieurs autres qui prennent en charge différents protocoles réseau. Nous ne les avons pas utilisés ici, mais certains autres modules populaires incluent:

  • + mod_proxy_ftp + pour FTP.

  • + mod_proxy_connect + pour le tunneling SSL.

  • + mod_proxy_ajp + pour AJP (protocole Apache JServ), comme les moteurs basés sur Tomcat.

  • + mod_proxy_wstunnel + pour les sockets Web.

Pour en savoir plus sur + mod_proxy +, vous pouvez lire la documentation officielle d’Apache + mod_proxy +.