Ecriture d'un module pour le serveur #http #nginx

J'ai développé un petit module de test pour le fameux serveur HTTP NGINX.

Ce module ne sert qu'a jouer avec la configuration et les librairies du serveur,
d'où son nom : nginxsandbox.

Le code C du module est disponible dans lemon-labs de github.

J'ai aussi écrit un shell permettant d'automatiser la compilation et le test d'un module Nginx : monmake.sh

make clean
./configure  --with-debug --with-http_stub_status_module  --add-module=/usr/local/nginxsandbox/
make
make install
cp /root/nginx.conf /usr/local/nginx/conf/
kill `cat /usr/local/nginx/logs/nginx.pid`
sleep 3
/usr/local/nginx/sbin/nginx > /usr/local/nginx/logs/error.log

Ce script est à installé dans le répertoire des sources du serveur.

Il suffit ensuite de créer un répertoire abritant votre module en dehors de cette arborescence.

Le script commence par faire le ménage dans le répertoire de compilation, puis lance le programme de configuration avec les bonnes options. Pour ma part,j'ai donc ajouté le module nginx status et le mien.
Après le make install, je recopie une sauvegarde de mon fichier de conf dans le répertoire de conf du daemon nginx.

Enfin, je coupe le serveur et je le relance.

Faire pointe pointer le browser sur localhost/sandbox doit donner :
(clic pour agrandir)



Le fichier de conf est modifié de la sorte :

       location /nginx_sandbox {
                sandbox on;
        }

La lecture du "guide d'emiller" est le point de départ à l'écriture d'un module.
Ainsi paré de la ceinture de Batman, l'aventure peut commencer.

Premiers pas avec le serveur web NGINX

J'ai procédé à des essais avec le serveur HTTP NGINX.

Pourquoi utiliser NGINX plutôt qu'Apache ? La réponse est ici: lien vers presentation.

Extraits:
Consommation mémoire:


Nombre de requetes délivrées:




Le secret de nginx réside dans l'application de deux principes:
* Le traitement concurrent (parallèle ) d'une requete.
* Un soin particulier porté dans l'écriture du code.

Nginx est particulièrement adapté pour faire du reverse-proxy et de la répartition de charge.

Installation de nginx.

Une fois que l'archive décompressée, j'ai lancé la commande :
./configure --without-http_rewrite_module --with-debug

Puis make et make install.


J'ai obtenu un répertoire nginx avec l'arborescence suivante:

ginx/conf:
fastcgi.conf koi-utf nginx.conf
fastcgi.conf.default koi-win
fastcgi_params mime.types nginx.conf.default
fastcgi_params.default mime.types.default win-utf


nginx/html:
50x.html index.html

nginx/logs:
access.log error.log nginx.pid

nginx/sbin:
nginx

Lancement.

Le fichier nginx.conf qui contiendra toute la configuration directement ou par un système d'include (ex: include mime.types; ) .


Le service se lance par la commande sbin/nginx et s'arrete par un kill PID.

Le serveur se lance sans modification du fichier de configuration et se met à l'écoute du port 80. Il utilise deux processus par défaut:

9775 ? Ss 0:00 nginx: master process sbin/nginx
9776 ? S 0:00 nginx: worker process



La vérification par telnet localhost 80
GET /
Donne un bienvenue : welcome to NGINX !

Activation du mode Proxy.

J'ai une application Rails qui fonctionne sur la même machine sous serveur mongrel sur le port 3000.

J'ai modifié nginx.conf comme ceci :

server {
listen 80;
server_name localhost;

#charset koi8-r;
#access_log logs/host.access.log main;
location / {
proxy_pass http://localhost:3000;
proxy_set_header X-Real-IP $remote_addr;
}

... continuation

Une requete sur http://localhost/ pointe à présent sur l'application Rails.

Les journaux d'accès ou d'erreur sont dans le répertoire nginx/logs

Répartition de charge #apache , #nginx et #tomcat

On dispose de plusieurs solutions pour répartir le trafic HTTP sur plusieurs serveurs WEB.

• Par DNS

C'est la solution la plus simple, la moins onéreuse mais aussi la moins efficace.
En faisant correspondre plusieurs adresses IP à une entrée DNS, une répartition de type round-robin (tourniquet) sera réalisée par le serveur DNS. Mais cette répartition ne tient pas compte des stratégies de cache des DNS intermédiaires et du cache client. De plus la gestion des pannes d'un des serveurs n'est pas prévue.

• Par un frontal Apache.

Il est courant de placer devant plusieurs serveur WEB un Apache fonctionnant en reverse proxy. Cette architecture peut avoir plusieurs objectifs : répartir la charge entre les serveurs applicatifs et servir de frontal à des serveur des servlets hébergés par TOMCAT.



Le module d'apache mod_proxy_balancer est actuellement le système le plus abouti pour réaliser cette tache.
Il propose une répartition allant du simple round-robin jusqu'à des algorithmes basés sur la charge réelle, la pondération des serveurs et des tables d'association.
Il permet aussi l'affinité des sessions: je commence sur un serveur et je reste collé sur ce serveur durant toute ma session (mode sticky sessions)

Un page d'administration est proposée par ce module:



Site de référence ici.

• Par un frontal NGiNX.

Le serveur NGiNX se positionne comme une alternative à Apache. Ce serveur est très compact, il fait appel à un code C très optimisé. Il est le 3eme serveur web utilisé dans le monde:

Apache         664,576 66.89% 665,593 66.98% 0.09
Microsoft 175,278 17.64% 172,983 17.41% -0.23
nginx          40,084 4.03% 42,105 4.24% 0.20

Il est original par sa conception même : il basé sur un traitement asynchrone des requêtes, une requête n'étant pas traitée par un process mais par plusieurs en parallèle.

Il propose des modules tiers permettant de mettre en place du load-balancing.

Des modules messageries (imap,pop, SMTP) le transforme en proxy mail très efficace.

• Par un répartiteur de charge opensource HAproxy

Ce projet est porté par le francais Willy Tarreau.
Cette solution est utilisée par des Banques et des administrations.

• Par un répartiteur de charge commercial.

Des boitiers dédiés de type ALTEON placés en frontaux vous offrent differentes stratégies de répartitions: round-robin, par table associative (hash) , par poids des serveurs, par charges etc. avec toujours l'option d'affinité pour les sessions.

• Conclusion.

Il existe d'autres solutions comme par exemple 'pound' qui est une système minimaliste écrit en 'C' mais qui date un peu.
Il y a aussi des fonctions de répartition prévues par mod_jk



Il est là aussi possible de définir l'option d'affinité des sessions. Toutefois, il est préférable d'utiliser mod_proxy_balancer qui est plus récent que mod_jk.

D'une manière générale l'affinité des sessions se gère par un cookie placé par le serveur applicatif web et propre à chaque serveur. Ce cookie est intercepté par le frontal qui s'en sert pour savoir à quel serveur envoyer la requête.

Les dignes fils d'Apache

Bien apache soit un des projets historiques de serveur WEB, il se trouve concurrencé par deux nouveaux projets: Lighttpd et nginx

le détails des parts de marché sont sur le site news.netcraft.com

Apache : 50 %
Microsoft : 35 %
Google : 6 %
Lighttpd :1,6 %
nginx : 1,5 %

Aprés comparaison de lighttpd et nginx , mon choix se porterai sur nginx .


Sur le wiki de nginx se trouve un tableau comparant les modules d'apache, lighttpd et nginx.
Nginx a été ecrit à l'origine pour faire du proxy ,reverse proxy et du load balancing.
Un squelette est disponible pour écrire ses propres modules en c.