Installation

Pour installer Nginx, commencez par installer les dépendances nécessaires, puis le paquet Nginx lui-même.

sudo yum -y install pcre-devel zlib-devel openssl openssl-devel
sudo yum -y install epel-release
sudo yum -y install nginx
sudo yum -y install nginx-all-modules.noarch

Configuration du démarrage automatique

Assurez-vous que Nginx démarre automatiquement au lancement du système et lancez-le.

systemctl enable nginx && systemctl start nginx

Commandes Nginx

Vous pouvez interagir avec Nginx via des commandes spécifiques. Deux méthodes principales sont disponibles :

• Naviguer vers le répertoire /usr/local/nginx/sbin et exécuter ./nginx.
• Utiliser la commande service nginx.

Afficher la version

# Méthode 1
./nginx -v

# Méthode 2
service nginx -v

Démarrer Nginx

# Méthode 1
./nginx

# Méthode 2
service nginx start

Arrêter Nginx

# Méthode 1
./nginx -s stop

# Méthode 2
service nginx stop

Recharger la configuration

Ceci permet de recharger le fichier de configuration sans redémarrer le serveur.

# Méthode 1
./nginx -s reload

# Méthode 2
service nginx reload

Redémarrer Nginx

service nginx restart

Valider la syntaxe de la configuration

nginx -t

Structure du fichier de configuration Nginx

Le fichier de configuration principal de Nginx se trouve généralement à /usr/local/nginx/conf/nginx.conf ou /etc/nginx/nginx.conf.

Il est composé de trois blocs principaux :

• Bloc global
• Bloc events
• Bloc http

Bloc global

Ce bloc contient les directives qui affectent le fonctionnement général du serveur Nginx. Il peut définir l'utilisateur et le groupe sous lesquels Nginx s'exécute, le nombre de processus worker, le chemin du fichier PID, les chemins et les types de journaux, ainsi que l'inclusion d'autres fichiers de configuration.

Exemple :

worker_processes 1;

La directive worker_processes est cruciale pour la gestion de la concurrence. Une valeur plus élevée permet de traiter plus de requêtes simultanément, mais elle est limitée par les ressources matérielles et logicielles disponibles.

Bloc events

Ce bloc concerne la gestion des connexions réseau entre Nginx et les clients. Les directives courantes incluent la sérialisation des connexions pour plusieurs processus worker, l'autorisation de recevoir plusieurs connexions simultanément, le choix du modèle de pilotage des événements et le nombre maximal de connexions par processus worker.

Exemple :

worker_connections 1024;

Cet exemple spécifie que chaque processus worker peut gérer jusqu'à 1024 connexions simultanées.

Bloc http

Ce bloc a un impact significatif sur les performances de Nginx et doit être configuré avec soin. C'est ici que la plupart des fonctionnalités et des configurations de modules tiers sont définies, y compris le proxy, la mise en cache et la définition des journaux.

Le bloc http peut lui-même contenir un bloc global http et plusieurs blocs server.

Bloc global http

Les directives dans ce bloc comprennent l'inclusion de fichiers, la définition des types MIME, la personnalisation des journaux, les délais d'attente des connexions et la limite du nombre de requêtes par connexion.

Bloc server

Ce bloc est étroitement lié au concept de virtual hosts (hôtes virtuels). Chaque bloc server représente un hôte virtuel, permettant à un seul serveur physique d'héberger plusieurs sites web. Chaque bloc http peut contenir plusieurs blocs server.

Un bloc server peut être divisé en un bloc server global et plusieurs blocs location.

Bloc server global

Les configurations les plus courantes ici sont les directives d'écoute (listen) pour les adresses IP et les ports, ainsi que la configuration du nom de l'hôte.

Bloc location

Un bloc server peut contenir plusieurs blocs location. Ils sont utilisés pour faire correspondre les requêtes entrantes à des URIs spécifiques et déterminer comment les traiter. Nginx utilise une logique de correspondance pour trouver le bloc location le plus approprié.

Règles de location

La syntaxe générale est :

location [ = | ~ | ~* | ^~ ] uri {
    # directives
}

• = : Correspondance exacte de l'URI. La recherche s'arrête ici.
• ~ : Correspondance d'URI avec une expression régulière, sensible à la casse.
• ~* : Correspondance d'URI avec une expression régulière, insensible à la casse.
• ^~ : Correspondance d'URI sans expression régulière. Si trouvé, la recherche d'expressions régulières est ignorée.

Important : Si l'URI contient une expression régulière, il faut utiliser ~ ou ~*.

Équilibrage de charge (Load Balancing)

L'équilibrage de charge est essentiel pour distribuer le trafic sur plusieurs serveurs, garantissant ainsi la disponibilité et la rapidité des services. Nginx offre des solutions d'équilibrage de charge efficaces.

Voici les stratégies d'équilibrage de charge proposées par Nginx :

1. Round Robin (par défaut) : Chaque requête est assignée séquentiellement à un serveur backend. Les serveurs indisponibles sont automatiquement retirés.

2. Pondération (Weight) : La directive weight permet d'attribuer un poids à chaque serveur. Un poids plus élevé signifie qu'un serveur recevra plus de requêtes. Utile lorsque les serveurs ont des performances différentes. ```nginx

   upstream myservices { server 127.0.0.1:81 weight=5; server 127.0.0.1:82 weight=10; }

3. IP Hash : Chaque requête est assignée à un serveur backend en fonction du hash de l'adresse IP du client. Cela garantit qu'un visiteur accède toujours au même serveur, résolvant ainsi les problèmes de session. ```nginx

   upstream myservices { ip_hash; server 127.0.0.1:81; server 127.0.0.1:82; }

4. Fair (module tiers) : Les requêtes sont distribuées en fonction du temps de réponse des serveurs backend. Les serveurs répondant plus rapidement sont privilégiés. ```nginx

   upstream myservices { server 127.0.0.1:81; server 127.0.0.1:82; fair; }

Proxy et équilibrage de charge TCP

Nginx peut également être utilisé pour le proxy et l'équilibrage de charge de connexions TCP.

Exemple pour rediriger les ports 9090 et 9091 vers 7878 et 7879 :

# Ajouter à la fin du fichier nginx.conf
stream {
    # Groupe de serveurs pour l'équilibrage de charge TCP
    upstream tcp_port_balance {
        server 127.0.0.1:7878 weight=5;
        server 127.0.0.1:7879 weight=5;
    }

    # Configuration du serveur pour le port 9090
    server {
        listen 9090;
        proxy_connect_timeout 20s;
        proxy_timeout 5m;
        proxy_socket_keepalive off;
        proxy_pass tcp_port_balance;
    }

    # Configuration du serveur pour le port 9091
    server {
        listen 9091;
        proxy_connect_timeout 20s;
        proxy_timeout 5m;
        proxy_socket_keepalive off;
        proxy_pass tcp_port_balance;
    }
}

Séparation du contenu statique et dynamique

La séparation du contenu dynamique et statique consiste à acheminer les requêtes dynamiques vers des serveurs d'applications (comme Tomcat) et les requêtes statiques (HTML, CSS, JS, images) vers Nginx pour un traitement plus rapide.

Il existe deux approches principales :

1. Héberger les fichiers statiques sur un domaine distinct, potentiellement sur des serveurs dédiés (approche recommendée).
2. Gérer les fichiers statiques et dynamiques sur le même serveur et utiliser Nginx pour les différencier.

La configuration des blocs location permet de spécifier comment gérer les requêtes basées sur leurs suffixes. L'utilisation de la directive expires permet de configurer la mise en cache par le navigateur, réduisant ainsi le trafic et la charge serveur pour les ressources qui ne changent pas fréquemment.

Exemple de configuration pour servir des fichiers statiques :

location /html/ {
    root    /mydata/static/html/; # Chemin vers les fichiers HTML sur le serveur
    autoindex on; # Active l'affichage du contenu du répertoire
}

location /css/ {
    root    /mydata/static/css/;  # Chemin vers les fichiers CSS
}

location /js/ {
    root    /mydata/static/js/;   # Chemin vers les fichiers JavaScript
}

location /image/ {
    root    /mydata/static/image/; # Chemin vers les fichiers images
}

Dans cet exemple, expires 3d (non montré dans le code mais mentionné dans le texte original) définirait une durée de vie de 3 jours pour les ressources mises en cache. Cela permet au navigateur de vérifier si le fichier a été modifié (via un If-Modified-Since header) avant de le télécharger à nouveau.