Contenu | Rechercher | Menus
Selon les tags présents sur cette page, les informations qu'elle contient n'ont pas été vérifiées depuis Ubuntu 10.04 LTS.
Apportez votre aide…

Table des matières


Configuration d'un proxy inverse et cache avec nginx

Ce tutoriel montre la configuration de nginx en tant que reverse proxy cache.

Cette configuration contiendra les éléments suivants:

  • Cache au niveau du reverse proxy
  • Activation des champs expires dans la requête http
  • Compression entre le client et le reverse proxy
  • Limitation des connexions entre le client et le reverse proxy (nombre et temps)

Pré-requis

Configuration

Certains termes présents dans cet article ne sont pas très "académiques" n'hésitez pas à les modifier si vous les connaissez.

La configuration qui va suivre se décomposera en trois parties :

  • Le paramétrage global du serveur nginx.
  • Le paramétrage des fonctions de reverse proxy et de cache.
  • Un exemple de configuration du serveur web se trouvant derrière le reverse proxy.

Les fichiers et les dossiers de configuration utilisés seront :

/etc/nginx/nginx.conf
/etc/nginx/conf.d/proxy.conf
/etc/nginx/sites-enabled/
/etc/nginx/sites-available/

Cette séparation a pour but d'ajouter de la clarté dans la configuration car tous les fichiers de configuration sont inclus dans le fichier nginx.conf.

Configuration globale du serveur

La configuration se fait dans le fichier /etc/nginx/nginx.conf

Contenu du fichier

user www-data;
worker_processes  1;
error_log  /var/log/nginx/error.log;
pid        /var/run/nginx.pid;
events {
	worker_connections  1024;
}
http {
    include       /etc/nginx/mime.types;
    default_type application/octet-stream;
    access_log  /var/log/nginx/access.log;
    sendfile        on;
    #tcp_nopush     on;
    #keepalive_timeout  0;
    keepalive_timeout  65;
    tcp_nodelay        on;
    # envoi moins d'information sur le serveur
    server_tokens off;

     # taille des buffers et taille max des requêtes normales
    client_body_buffer_size 1k;
    client_max_body_size    8m;
    large_client_header_buffers 1 1K;
    ignore_invalid_headers on;
    
    
    # définition des différents timeout
    client_body_timeout 5;
    client_header_timeout 5;
    keepalive_timeout 5 5;
    send_timeout 5;
    ignore_invalid_headers on;
    server_name_in_redirect off;
    
    
    # active la compression des pages sauf pour les navigateurs pourris
    gzip  on;
    gzip_comp_level 6;
    gzip_proxied any;
    gzip_vary on;
    gzip_types  text/plain text/css application/x-javascript;
    gzip_disable "MSIE [1-6]\.(?!.*SV1)";
    
    # limitation du nombre de connexion par client
    limit_zone gulag $binary_remote_addr 1m;
    limit_conn gulag 50;

    include /etc/nginx/conf.d/*.conf;
    include /etc/nginx/sites-enabled/*;
}
options explications
user utilisateur avec lequel sera lancé le processus, celui ci doit avoir le moins de privilèges possible
worker_processes correspond au nombre de cœurs
worker_connections fixer ce paramètre en fonction du calcul ci dessous (valable que sur un reverse proxy) max_clients = worker_processes * worker_connections/4
access_log chemin vers le fichier log des connexions
error_log chemin vers le fichier log des erreurs
default_type type par défaut des fichiers dont le type n'est pas répertorié dans le fichier mimes.types
server_tokens off permet de divulguer moins d'informations sur le reverse proxy
client_body_buffer_size définit la taille au delà de laquelle la requête sera enregistrée dans un fichier
client_max_body_size taille max des données envoyées par un client
large_client_header_buffers définit le nombre de buffer ainsi que leurs tailles, la taille max de la requête URI est donc la multiplication de ces deux chiffres
client_body_timeout si le client n'envoie pas la totalité de sa requête en 5 sec c'est mort !
client_header_timeout si le client n'envoie pas l'entête de sa requête même traitement
keepalive_timeout 5 5 premier chiffre temps max d'une connexion keepalive, deuxième chiffre indication de cette valeur dans le champ timeout de l'entête de la réponse
keepalive_requests 100 nombre de requêtes keepalive sur une connexion
send_timeout temps maximum de latence lors d'un envoi
ignore_invalid_headers supprime les requêtes malformées
server_name_in_redirect désactive la réécriture du nom de serveur, protection contre les scans
gzip activation ou désactivation de la compression
gzip_comp_level niveau de compression (peut aller jusqu'à 9)
gzip_proxied any activer la compression pour la réponse du serveur web derrière le reverse proxy
gzip_vary active l'entête http "Vary: Accept-Encoding"
gzip_types les types de fichier qui seront compréssés
gzip_disable permet la désactivation de la compression pour les navigateurs pourris
limit_zone gulag $binary_remote_addr 1m crée une zone de stockage nommée « gulag » utilisant moins de 1 mo de RAM, contenant l'état des connexions classé par adresse ip
limit_conn gulag 50 limite le nombre de demande de connexions parallèles à 50 par client

Paramétrage des fonctions reverse proxy et cache

Les paramètres du reverse proxy et du cache seront consignés dans le fichier /etc/nginx/conf.d/proxy.conf pour plus de clarté.

Si vous voulez plus d'informations sur la configuration du proxy, allez voir la section de la documentation officielle ici.

Contenu du fichier

proxy_redirect          off;
proxy_set_header        Host            $host;
proxy_set_header        X-Real-IP       $remote_addr;
proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_hide_header       X-Powered-By;
proxy_intercept_errors on;
proxy_buffering on;


proxy_cache_key "$scheme://$host$request_uri";
proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=cache:10m inactive=7d max_size=700m;
options explications
proxy_redirect off permet une réécriture de l'adresse, inutile quand le serveur web ne se trouve pas sur la même machine physique
proxy_set_header permet de modifier les entêtes
proxy_hide_header permet de cacher certains entêtes
proxy_intercept_errors on permet de contrôler les retours de code d'erreur du serveur web et de les modifier à la volé
proxy_buffering on Si l'on désactive cette option le serveur arrière doit attendre que les données soient envoyées au client pour fermer sa connexion avec nginx
proxy_cache_min_uses 3 La ressource devra être demandée 3 fois avant d'être mise en cache
proxy_cache_key clé permettant de stocker des fichiers de plusieurs sites différents dans le même cache. Les noms de fichiers seront le md5 de cette combinaison
proxy_cache_path indique le chemin vers le dossier de cache, organisation des dossiers ( Si quelqu'un a plus d'information sur cette directive, sa participation est la bienvenue)
level 1:2 indique l'organisation des dossiers,
keys_zone définit le nom de cette zone, inactive définit le temps de conservation maximum d'un élément sans qu'il soit demandé par un client. Si le temps imparti est épuisé l'élément est supprimé,
max_size indique la taille maximale du cache

Exemple de configuration d'un serveur web arrière

Nous allons créer le fichier trucbidule dans le répertoire /etc/nginx/sites-available/.

Les éléments de la configuration :

  • les requêtes arrivant sur le port 80 et ayant pour nom de domaine de destination trucbidul.fr seront redirigées vers le serveur web ayant l'adresse 192.168.0.100
  • seules les méthodes GET,HEAD et POST seront acceptées
  • tous les fichiers seront mis en cache minimum 12 heures
  • les fichiers statiques seront mis en cache 2 jours
  • pas de mise en cache pour la section administration du site
  • le champs expires de la requête http seront remplis
  • les codes d'erreurs seront interceptés et une page sera renvoyée

Contenu du fichier trucbidule:

server {

    listen 80;
    server_name www.trucbidule.fr trucbidule.fr;

    # Ici on désactive les access_log pour ne pas faire doublon avec Apache
    access_log off;
    #access_log /var/log/nginx/default.access.log;

if ($request_method !~ ^(GET|HEAD|POST)$ ) {
return 444;
}


location / {
    proxy_pass http://192.168.0.100:80/;
    proxy_cache cache;
    proxy_cache_valid 12h;
    expires 12h;
    proxy_cache_use_stale error timeout invalid_header updating;
}


location ~*^.+(swf|jpg|jpeg|gif|png|ico|css|zip|tgz|gz|rar|bz2|doc|xls|exe|pdf|ppt|txt|tar|mid|midi|wav|
bmp|rtf|js)$ {
    proxy_pass http://192.168.0.100:80;
    proxy_cache cache;
    proxy_cache_valid 2d;
    expires max;
}


location ^~ (^/admin|^/identification) {
    proxy_pass http://192.168.0.100:80;
}

error_page 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 500 501 502 503 504 505 506 507 /error.html;

location = /error.html {
    root /var/www/nginx-default;
}
}
options explications
listen adresse et port d'écoute, ici il écoute sur toutes les adresses
server_name nom de domaine du serveur arrière, possibilité d'en spécifier plusieurs
error_page redirection des erreurs suivantes vers le chemin indiqué
proxy_pass indique l'adresse du serveur web arrière
proxy_cache_valid 12h toutes les pages retournant avec un code 200 301 et 302 seront stockées en cache pendant 12 heures. Il est possible de spécifier les codes html pour lesquels les fichiers doivent être mis en cache
proxy_cache indique la zone de stockage pour le cache
proxy_cache_use_stale Si le serveur arrière renvoi ces erreurs error timeout invalid_header updating nginx servira les fichiers qu'il possède en cache
expires max donne une date d'expiration maximale pour que le client puisse mettre les fichiers statiques en cache

Quelque explications sur notre configuration. Comme vous l'avez vu toutes les requêtes ne sont pas traitées de la même manière. Différentes règles ont été créées pour séparer les contenus.

  • Si l'adresse commence par un / (c'est à dire tout le temps) les éléments sont mis en cache pendant 12 h.
  • Si l'adresse se termine par une des extensions de fichiers listées, alors les éléments sont mis en cache pendant 2 jours.
  • Si l'adresse commence par /admin ou /administration il n'y a pas de mise en cache.
  • Si l'adresse correspond à /error.html alors un fichier local est servit.

Comme vous pouvez vous rendre compte dans certains cas plusieurs règles sont remplies. Il y a donc une hiérarchie parmi ces règles. La documentation officielle traite de ce sujet ici.

Pour résumer, voici la hiérarchie :

  1. = Lorsque l'adresse est exactement la même la condition est remplie et les autres règles ne sont pas vérifiées.
  2. ^~ Lorsque l'adresse commence par l'expression les autres règles ne sont pas vérifiées.
  3. ~ Les expressions régulières sont analysées dans leur ordre d'apparition dans le fichier.
  4. Finalement la règle location / correspondant à tous les cas est appliquée dans le cas où l'adresse ne remplie pas les conditions des règles précédentes.

Vous avez peut-être remarqué dans le fichier de configuration une petite étoile après la vague ~* . Cela indique que la règle n'est pas sensible a la casse.

Il suffit, pour activer ce serveur, de créer un lien symbolique pointant vers le fichier précédent dans le répertoire :

sudo ln -s /etc/nginx/sites-available/trucbidule /etc/nginx/sites-enabled/trucbidule

Load balancing

Il est possible de faire du load balancing avec nginx d'une manière assez simple. Il suffit de déclarer un groupe de serveurs et d'envoyer les requêtes vers ce groupe d'hôtes avec la directive proxy_pass. La documentation officielle détaillant la procédure ainsi que toutes les options possibles est disponible ici.

Voici l'exemple de la documentation officielle :

upstream backend  {
  server backend1.example.com weight=5;
  server backend2.example.com:8080;
  server unix:/tmp/backend3;
}
 
server {
  location / {
    proxy_pass  http://backend;
  }
}

Voir aussi


tutoriel/reverse_proxy_nginx.txt · Dernière modification: Le 27/11/2013, 10:53 par 81.80.58.142
Le contenu de ce wiki est sous licence : CC BY-SA v3.0