Coupler Nginx et Tomcat pour déployer une application JavaEE

 Article modifié dernièrement le 11 Juin 2013 @ 17 h 13 min

Après vous avoir présenté dans un article précédent des Taglibs JSP qui permettent de réduire considérablement le poids de nos pages Web ainsi que d’améliorer leur vitesse de téléchargement, je me suis attaqué à une optimisation au niveau de l’infrastructure du serveur Web.

nginx_tomcat_mysql

J’avoue qu’au départ je comptais partir sur une base Apache + Tomcat + mod_jk pour déployer mon application JavaEE, j’allais me calquer tout bêtement sur mon environnement de développement qui est géré par XAMPP.

Mais bon finalement rien de mieux que de s’aventurer dans l’inconnu, l’ancien trio devient alors Nginx + Tomcat + proxy_pass, du lourd.

Nginx (Engine X)

Bien qu’Apache soit le serveur Web le plus utilisé, il est vieillissant et basé sur des processus multiples (multi-thread) lancés à l’initialisation de celui-ci et dont le nombre est déterminé à l’avance. Nginx, quant à lui, est régit par un processus maître qui génère à la volée un processus par requête qu’il reçoit, il fait partie de la famille des serveurs Web asynchrones.

Nginx est un serveur asynchrone par opposition aux serveurs synchrones où chaque requête est traitée par un processus dédié. Au lieu d’exploiter une architecture parallèle et le multiplexage temporel des tâches par le système d’exploitation, Nginx utilise les changements d’états pour gérer plusieurs connexions en même temps ; le traitement de chaque requête est découpé en de nombreuses mini-tâches et permet ainsi de réaliser un multiplexage efficace entre les connexions. Afin de tirer parti des ordinateurs multi-processeurs, plusieurs processus peuvent être démarrés. Ce choix d’architecture se traduit par des performances très élevées mais également par une charge et une consommation de mémoire particulièrement faibles comparativement aux serveurs HTTP classiques tels qu’Apache.

  • Configuration du fichier nginx.conf

Tomcat inclut un serveur Web Apache par défaut qui permet d’accéder à vos applications déployées sur le port 8080 http://localhost:8080/mon_appli_java_web, nous souhaitons donc qu’Nginx serve de relais (proxy) et délivre sur le port 80 l’application Tomcat lorsque l’url suivante est utilisée http://localhost/mon_appli_java_web.

Pour cela Nginx devra utiliser son module proxy_pass, inclut et activé par défaut, qui permet de transférer certaines requêtes qu’il reçoit vers un autre serveur (dans notre cas vers Tomcat).

Voici un exemple de configuration simplifié :

A noter qu’il est facile d’utiliser ce cas pour un nom de domaine autre que localhost qui représente le nom de votre machine locale.

  • Utilisation avec un nom de domaine

En remplaçant server_name 127.0.0.1; par exemple par server_name mon_domaine.com; nous voilà désormais redirigé vers notre Tomcat local lorsque l’on saisit comme url http://mon_domaine.com. Ce qui se traduit par la possibilité d’héberger et rendre disponible plusieurs applications Java depuis son Tomcat en y accédant tout simplement par les urls http://mon_domaine.com/mon_blog ou http://mon_domaine.com/mon_forum.

PS : pour que votre nom de domaine pointe sur votre machine locale (ou une machine dédiée dans les nuages), il faut préalablement avoir configuré l’IP cible de votre nom de domaine au niveau de votre Bureau d’enregistrement (ou Registar).

Tomcat

Au niveau de Tomcat il n’y a pas grand chose à faire si ce n’est que les contextes « mon_blog » ou « mon_forum » soient reconnus et redirigent correctement sur l’application/site correspondante.

Pour ma part j’ai eu de nombreux problèmes avec le « context path » d’une application lorsque je la déployais à chaud en déposant le .war dans le répertoire webapps de Tomcat, du coup je procède dorénavant autrement pour ne plus avoir de problème et choisir comme je l’entends le « context path » de mes applications indépendamment du nom de l’archive qui prime par défaut dans le cas du déploiement à chaud (dans notre cas « /mon_blog » ou « /mon_forum »).

  • Fichier de contexte séparé

Il suffit pour cela de se rendre dans le répertoire Tomcat/conf/Catalina/localhost et déposer un fichier xml qui aura pour nom le contexte de votre application que vous voulez déployer.

Exemple du contenu du fichier « mon_blog.xml » qui recherche l’archive à déployer (le_nom_de_mon_archive.war) dans le répertoire Tomcat/perso et crée une ResourceLink en pointant sur une ressource établie au niveau du fichier server.xml de Tomcat (jdbc/dbYYY) :

  • Déploiement

Au démarrage de Tomcat, l’application est déployée dans un répertoire nommée mon_blog au niveau du répertoire Tomcat/webapps, ce qui fait que l’url http://localhost/mon_blog est bien accessible et exécute l’application contenue dans le fichier Tomcat/perso/le_nom_de_mon_archive.war.

Pour l’application mon_forum il suffit de procéder de la même façon et le tour est joué, Nginx et Tomcat sont à présent configurés pour fonctionner ensemble.

Trois flèches vers le bas

1- Logiciel de brouillage d’adresse IP :

Contourner la censure en surfant anonyme

2- L’article explicatif :

La différence entre un proxy et un VPN

3- Comment espionner un smartphone (app) :

L’application de référence

Commentez ici

  • Greg 19 mai 2011, 1 01

    Tes explications sur la vitesse avancent, ça tombe bien c’est souvent le nerf de la guerre sur la toile. Perso. j’ai fait quelques découvertes je t’en parlerai un de ces quatre ^^

  • Seb 29 juin 2011, 15 03

    Je ne suis pas convaicu par cette affirmation :
    « Bien qu’Apache soit le serveur Web le plus utilisé, il est vieillissant et fonctionne de manière synchrone en n’exploitant qu’un seul (gros) processus »

    Extrait Wikipedia :
    Les modes Prefork et Worker[modifier]

    Ces deux grands modes de fonctionnement changent notamment les performances du serveur HTTP.

    Historiquement, Apache fonctionne en Prefork, ce qui signifie qu’un processus père lancé avec de grands droits (root) pré-execute des processus enfants qui traiteront chacun un certain nombre de requêtes clients. Cependant, sous Linux, la multiplication des processus provoque une augmentation de consommation de ressources.

    En mode Worker, Apache lance des threads qui géreront les demandes entrantes. La différence est qu’il s’agit d’un mode plus préemptif dans lequel le processus père prépare les ressources pour ses threads.

    Il y a donc plusieurs threads (processus léger) pouvant traiter les requêtes.

    Autre question, vu que nginx transfere toutes les requetes à Tomcat, qui va empecher tomcat de s’ecrouler ? avec un bon vieux mod_jk on peut dire à httpd de s’occuper de certains fichiers statiques …

  • Mimie 29 juin 2011, 16 04

    Le billet présente la configuration Nginx pour faire des appels vers Tomcat, l’exemple se veut simple et donc tout est redirigé vers Tomcat.
    Je n’ai donc pas parlé de la possibilité de filtrer les requêtes demandant des ressources statiques, voici une façon de faire (code à insérer dans le bloc server{}) :

    location ~* ^.+\.(jpg|jpeg|gif|png|ico|css|zip|tgz|gz|rar|bz2|pdf|txt|tar|wav|bmp|rtf|js|flv|swf|html|htm)$
    {
        root   /var/www/your-static-content-folder;
    }
    
  • Mimie 29 juin 2011, 16 04

    Pour l’affirmation que tu as souligné, tu as en effet raison, je me suis mal renseigné, c’est corrigé.

  • Pierre 14 mars 2014, 14 02

    Tutoriel sympa qui à le mérite d’être clair. Je voudrais simplement faire la remarque suivante; une fois que Tomcat est disponible (installé) sur le serveur l’accès direct est possible par le port 8080. ex : Un serveur avec l’adresse ip 25.100.100.99 donnera avec la configuration par défaut un accès tel que 25.100.100.99:8080. On peut cependant restreindre l’accès à Tomcat uniquement en passant par Nginx à l’aide d’une directive dans le fichier server.xml de Tomcat.
    ex (pour ce serveur): au niveau de . Ce qui évite un accès qui ne passerais pas par Nginx …

  • Pierre 14 mars 2014, 14 02

    Un passage de mon commentaire a été supprimé, donc je précise, pour ce serveur, la balise xml suivante :
    Valve className= »org.apache.catalina.valves.RemoteAddrValve » allow= »25\.100\.100\.99″, au niveau de Engine name= »Catalina » defaultHost= »localhost ».
    ah le xss …

  • Mimie 15 mars 2014, 21 09

    Merci, bonne astuce 🙂

Article suivant:

Article précédent:

Share This