Objectif
Notre objectif est de configurer Apache httpd pour qu'il fonctionne comme proxy devant le conteneur d'application Apache Tomcat.
Versions du système d'exploitation et du logiciel
- Système d'exploitation : Red Hat Enterprise Linux 7.5
- Logiciel : Apache httpd, Apache Tomcat
Exigences
Accès privilégié au système
Difficulté
FACILE
Congrès
- # - nécessite que les commandes linux données soient exécutées avec les privilèges root soit directement en tant qu'utilisateur root, soit en utilisant
sudocommande - $ – commandes linux données à exécuter en tant qu'utilisateur normal non privilégié
Présentation
L'utilisation d'Apache httpd comme proxy vers un conteneur d'application Apache Tomcat est une configuration courante. Il est livré avec de nombreux cas d'utilisation, le plus trivial est de servir du contenu statique à partir de httpd , tout en fournissant des services implémentant une logique métier lourde à partir d'une application écrite en Java qui réside dans le conteneur Tomcat.
En créant un proxy, nous pouvons créer une sorte de frontal vers la couche application, où nous pouvons introduire des mesures de sécurité dans le serveur Web, appliquer l'équilibrage de charge, utiliser la redirection conditionnelle ou utiliser toute autre fonctionnalité fournie par le serveur Web. De cette façon, nous n'avons pas besoin d'implémenter l'une de ces fonctionnalités dans notre application et pouvons concentrer ses capacités sur le service lui-même. Nous aurons un serveur Web complet présenté aux utilisateurs, certaines des URL transmises silencieusement au conteneur d'applications qui peuvent ne pas être accessibles par elles-mêmes. Les réponses de l'application sont renvoyées aux clients qui ne sauront pas qu'ils ont parlé autre chose que le serveur Web - c'est-à-dire si nous prenons soin de ne pas exposer d'informations (comme des messages d'erreur non gérés) de l'application qui peuvent leur faire deviner qu'il y en a d'autres plusieurs couches.
Nous utiliserons le protocole AJP qui peut être utilisé entre les serveurs Web et les conteneurs d'applications basés sur Java pour fournir la possibilité d'équilibrer la charge entre plusieurs serveurs d'applications. Toutefois, la configuration d'un équilibreur de charge n'entre pas dans le cadre de ce didacticiel.
Nous allons configurer notre configuration sur Red Hat Linux 7.5, mais le serveur Web Apache, le module AJP et le conteneur d'application Apache Tomcat sont disponibles partout, et donc cette configuration est portable avec de petits ajustements comme les chemins du système de fichiers ou les noms de service.
Installation du logiciel requis
Nous devons d'abord installer les services que nous utiliserons. Dans une configuration à charge équilibrée, le ou les serveurs Tomcat peuvent se trouver sur différentes machines, et ils le sont souvent, fournissant une batterie de conteneurs qui créent un service.
# yum install httpd tomcat tomcat-webapps
Nous installons les tomcat-webapps à des fins de test, ce package contient un exemple d'application Web déployée sur notre serveur Tomcat lors de l'installation. Nous utiliserons cette application pour vérifier que notre configuration fonctionne comme prévu.
Nous pouvons maintenant activer et démarrer notre serveur Tomcat :
# systemctl enable tomcat
# systemctl start tomcat
Et notre serveur Web :
# systemctl enable httpd
# systemctl start httpd
Le httpd par défaut l'installation contient les modules proxy dont nous avons besoin. Pour vérifier qu'il en est ainsi, nous pouvons interroger le serveur Web avec apachectl :
# apachectl -M | grep ajp
proxy_ajp_module (shared)
Remarque :les versions 1.x d'Apache utilisent mod_jk module au lieu de proxy_ajp .
Configuration httpd
Les exemples d'application Web déployés dans Tomcat sont publiés après l'installation par défaut sur server-url:8080/examples . Nous transmettrons les requêtes proxy arrivant au port 80 du serveur (le port http par défaut) en demandant quelque chose au server-url/examples être servi par les examples application Web déployée dans Tomcat. Les demandes provenant de toute autre URL sur le serveur seront servies par le serveur Web. Nous allons mettre en place du contenu statique pour montrer cette fonctionnalité.
Dans notre exemple, le serveur s'appelle ws.foobar.com . Pour que le proxy fonctionne, créez un fichier texte avec votre éditeur préféré sous le répertoire de configuration du serveur Web, qui est /etc/httpd/conf.d sur les versions Red Hat, avec l'extension .conf . Notre configuration n'a pas besoin que Tomcat soit accessible directement, nous utilisons donc localhost comme hôte cible dans /etc/httpd/conf.d/example_proxy.conf fichier :
<VirtualHost ws.foobar.com:80>
ServerName ws.foobar.com
ProxyRequests Off
ProxyPass /examples ajp://localhost:8009/examples
ProxyPassReverse /examples ajp://localhost:8009/examples
</VirtualHost>
Pour plus de sécurité, nous pouvons vérifier que notre configuration est correcte avant de postuler avec apachectl :
# apachectl configtest
Syntax OK
Si le test de configuration renvoie une erreur comme celle-ci :
Could not resolve host name ws.foobar.com -- ignoring!
Si signifie que notre ServerName directive n'est pas valide, car elle ne peut pas être résolue par le serveur Web. Soit nous devons l'enregistrer dans le DNS (local ou global), soit fournir une ligne dans le /etc/hosts fichier contenant l'adresse IP publique de l'hôte suivie du nom que nous avons donné dans la configuration ci-dessus. Si le fichier hosts contient déjà l'adresse IP avec un autre nom (peut-être le vrai nom d'hôte), nous pouvons ajouter le nom du serveur après le ou les noms d'hôte dans la même ligne, la configuration fonctionnera.
Après un test réussi, nous devons appliquer la nouvelle configuration en redémarrant le serveur Web :
# systemctl restart httpd
Configuration Tomcat
Avec l'installation par défaut, le conteneur Tomcat écoutera les requêtes AJP sur toutes les interfaces du port 8009. Cela peut être vérifié dans le fichier de configuration principal :
# view /usr/share/tomcat/conf/server.xml
[..]
<!-- Define an AJP 1.3 Connector on port 8009 -->
<Connector port="8009" protocol="AJP/1.3" redirectPort="8443" />
[..]
Si nous n'avons pas besoin que le conteneur Tomcat et les applications qu'il contient soient accessibles par eux-mêmes, nous pouvons configurer chaque connecteur pour qu'il écoute uniquement sur localhost :
Connector address="127.0.0.1" port=..."
Pour postuler, nous pouvons redémarrer Tomcat avec :
# systemctl restart tomcat
Dans notre laboratoire, la machine ne le fera pas, car nous devons voir que nous recevons le même contenu sur les deux ports 80 et 8080 .
Test
Notre configuration minimale du proxy AJP est terminée, nous pouvons la tester. Depuis la ligne de commande, nous pouvons appeler les examples application directement sur le port 8080 :
$ wget http://ws.foobar.com:8080/examples
--2018-09-13 11:00:58-- http://ws.foobar.com:8080/examples
Resolving ws.foobar.com (ws.foobar.com)... 10.104.1.165
Connecting to ws.foobar.com (ws.foobar.com)|10.104.1.165|:8080... connected.
HTTP request sent, awaiting response... 302 Found
Location: /examples/ [following]
--2018-09-13 11:00:58-- http://ws.foobar.com:8080/examples/
Reusing existing connection to ws.foobar.com:8080.
HTTP request sent, awaiting response... 200 OK
Length: 1253 (1.2K) [text/html]
Saving to: 'examples'
100%[=========================================================================================================================================================================>] 1,253 --.-K/s in 0s
2018-09-13 11:00:58 (102 MB/s) - 'examples' saved [1253/1253]Et voir le contenu fourni :
$ tail examples
<h3>Apache Tomcat Examples</H3>
<p></p>
<ul>
<li><a href="servlets">Servlets examples</a></li>
<li><a href="jsp">JSP Examples</a></li>
<li><a href="websocket/index.xhtml">WebSocket (JSR356) Examples</a></li>
<li><a href="websocket-deprecated">WebSocket Examples using the deprecated
Apache Tomcat proprietary API</a></li>
</ul>
</body></html>Et si nous appelons la même application via notre proxy AJP, nous devrions également obtenir une réponse, alors qu'il n'y a aucun contenu dans la racine du document du serveur Web :
$ wget http://ws.foobar.com/examples
--2018-09-13 11:01:09-- http://ws.foobar.com/examples
Resolving ws.foobar.com (ws.foobar.com)... 10.104.1.165
Connecting to ws.foobar.com (ws.foobar.com)|10.104.1.165|:80... connected.
HTTP request sent, awaiting response... 302 Found
Location: /examples/ [following]
--2018-09-13 11:01:09-- http://ws.foobar.com/examples/
Reusing existing connection to ws.foobar.com:80.
HTTP request sent, awaiting response... 200 OK
Length: 1253 (1.2K) [text/html]
Saving to: 'examples.1'
100%[=========================================================================================================================================================================>] 1,253 --.-K/s in 0s
2018-09-13 11:01:09 (101 MB/s) - 'examples.1' saved [1253/1253]Si tout fonctionne, nous obtiendrons une réponse avec le même contenu, car la réponse finale est fournie par la même application dans le conteneur :
$ tail examples.1
<h3>Apache Tomcat Examples</h3>
[...]Nous pouvons également tester notre configuration avec un navigateur. Nous devons appeler toutes les URL avec le nom du serveur en tant qu'hôte (au moins celui qui est mandaté). Pour cela, la machine exécutant le navigateur doit être capable de résoudre le nom du serveur, au moyen du DNS ou du fichier hosts.
Dans notre environnement de laboratoire, nous n'avons pas désactivé l'écoute de Tomcat sur l'interface publique, nous pouvons donc voir ce qui est fourni lorsqu'il est demandé directement sur le port 8080 :
Tomcat fournissant les exemples d'application
Nous pouvons obtenir le même contenu via le proxy AJP fourni par le serveur Web sur le port 80 :
httpd fournissant les exemples d'application avec proxy AJP
Tout en agissant en tant que proxy, httpd peut servir tout autre contenu. Nous pouvons créer du contenu statique accessible sur une autre URL sur le même serveur :
# mkdir /var/www/html/static_content
# echo "<html><body>Static content</body></html>" > /var/www/html/static_content/static.htmlEn pointant notre navigateur vers cette nouvelle ressource, nous recevons le nouveau contenu statique.
Contenu statique fourni par httpd Si le conteneur Tomcat n'était pas accessible, nous ne saurions pas que la réponse viendrait ailleurs que sur le serveur Web. Comme nous n'avons mandaté qu'une application spécifique, l'application ROOT par défaut du conteneur n'est pas accessible via le proxy, donc cachée de tout au-delà du serveur Web.
Conclusion
Le serveur Web Apache est hautement extensible au moyen de modules, l'un d'eux est le module proxy AJP. Le guide ci-dessus utilise une machine et expose une application avec le proxy, mais le même serveur Web peut fournir une seule entrée à de nombreuses applications, éventuellement sur de nombreux hôtes exécutant des conteneurs d'applications, tout en fournissant également d'autres contenus Web.
Combiné avec d'autres modules, comme mod_security , nous pouvons ajouter de nombreuses fonctionnalités à notre service sans avoir besoin de les développer au sein de l'application, ou si le besoin s'en fait sentir, rediriger le proxy vers un autre point de terminaison avec une seule édition du fichier de configuration et le rechargement du serveur Web, en effectuant une migration ou l'introduction de la nouvelle version de l'application en quelques secondes. Le même rechargement peut conduire le visiteur vers une page expliquant les temps d'arrêt planifiés, tandis que la maintenance est effectuée sur les serveurs d'application - les cas d'utilisation d'un proxy AJP ne sont limités que par l'imagination du personnel informatique.