Guide Nginx en PDF (Intermédiaire)

Documentation sur Nginx : Ce qu'il faut savoir. Nginx est un serveur HTTP(S) léger et asynchrone conçu pour gérer un grand nombre de connexions simultanées via une architecture noyau + modules. Il sert fréquemment de reverse proxy et de terminator SSL dans des chaînes de mise en production. Il traite les requêtes du protocole HTTP de manière événementielle, multiplexant les connexions au sein d'un nombre limité de processus pour réduire l'empreinte mémoire par connexion, contrairement au modèle historique d'Apache fondé sur des processus/threads par connexion. Le document précise qu'Igor Sysoev a initié le projet en 2002 et décrit son usage fréquent en équilibrage de charge au niveau application (couche 7 du modèle OSI).

🎯 Objectifs d'apprentissage

• Architecture et avantages — comprendre le modèle événementiel, l'impact sur la latence réseau et les cas où le serveur surpasse Apache en haute concurrence.
• Séparation des configurations par domaine — organiser les vhosts avec sites-available et sites-enabled, et activer des domaines via des liens symboliques.
• Proxy inverse pour Zope/zwook — paramétrer proxy_pass et conserver l'en-tête Host via $host.
• Gestion des logs — configurer logrotate pour rotation, compression et rétention automatique.
• Intégration au démarrage — script init.d type pour start/stop/reload et mise en place via update-rc.d ou équivalent systemd.
• Optimisation Multi‑CPU — dimensionnement de worker_processes et worker_cpu_affinity pour une meilleure utilisation des cœurs.

📑 Sommaire du document

• Architecture et avantages
• Installation sur Debian
• Configuration des Vhosts
• Logrotate
• Script Init.d
• Optimisation Multi-CPU
• Cas pratique : proxy pour Zope/zwook

Architecture et avantages

Le serveur met en œuvre le protocole HTTP selon un modèle événementiel : un petit nombre de processus gère simultanément des milliers de connexions via des boucles d'événements et des descripteurs non‑bloquants. Cette organisation limite les context switches et la consommation mémoire par connexion, améliorant la latence réseau et la capacité en haute disponibilité. Dans le modèle OSI, l'optimisation intervient principalement à la couche 7 (application), avec des implications sur le caching, la terminaison TLS et l'équilibrage de charge applicatif. Les administrateurs tireront parti de cette architecture pour déléguer la gestion TLS au frontal et alléger la pile applicative côté backend.

Fonctionnement du protocole HTTP avec Nginx

Le fonctionnement HTTP repose sur la gestion asynchrone des sockets et le parsing efficace des en-têtes. Le serveur supporte HTTP/1.1 et HTTP/2 (si compilé avec les modules appropriés) et implémente des optimisations telles que keep-alive multiplexé et la gestion fine des timeouts. Comparé à Apache, le traitement événementiel réduit la surcharge par connexion et permet un throughput supérieur sur des charges de clients concurrents, sans augmenter linéairement le nombre de processus.

💡 Pourquoi choisir ce cours ?

Le document de Philippe Lafaye privilégie une approche pragmatique : extraits de configurations réelles, scripts d'init et fragments de logrotate prêts à l'emploi pour la production. Sa concision (7 pages) en fait une fiche opérationnelle destinée aux administrateurs souhaitant appliquer des modifications rapidement. Les exemples ciblent l'usage du serveur comme reverse proxy pour Zope/zwook et des recettes d'exploitation directement déployables, basées sur des bonnes pratiques d'administration système (rotation des logs, gestion des processus, affinité CPU).

👤 À qui s'adresse ce cours ?

• Public cible : administrateurs systèmes, ingénieurs DevOps et mainteneurs d'applications web responsables du déploiement d'un proxy inverse ou d'un serveur frontal pour des instances Zope/zwook.
• Prérequis : maîtrise de la ligne de commande Linux, éditeurs de texte pour modifier /usr/local/nginx/conf, notions HTTP/proxy et familiarité avec les scripts init et les permissions système.

Nginx vs Apache : Pourquoi migrer ?

Le modèle d'E/S non‑bloquant limite la consommation mémoire par connexion et réduit les context switches sous forte charge, rendant le serveur particulièrement adapté aux architectures à haute concurrence. Pour du contenu statique ou en frontal d'applications, on observe souvent une latence plus faible et un throughput supérieur sans augmentation significative des ressources machines. La fiche décrit les configurations et optimisations typiques permettant de tirer parti de ce comportement.

Commandes d'administration et de diagnostic

Outils et commandes essentiels pour tester, recharger et diagnostiquer le service sur Debian/Ubuntu ; adaptez les commandes pour CentOS ou systemd si nécessaire.

Commandes essentielles

• nginx -t — test de la configuration
• nginx -s reload — rechargement sans interruption
• systemctl status nginx — état du service (systemd)

Compatibilité système

Les exemples et scripts ciblent Debian/Ubuntu mais se transposent à d'autres distributions avec des adaptations (emplacement des fichiers, gestionnaire de services). Le serveur est également disponible sous Windows pour des environnements de test ou de développement ; en production, privilégier une plateforme Linux pour bénéficier des optimisations et de la gestion avancée des processus.

Logrotate et gestion des logs

Configurer la rotation et la compression des fichiers de logs évite le remplissage disque en production. Inclure une configuration pour /usr/local/nginx/logs/*.log et définir la rétention adaptée aux contraintes réglementaires et opérationnelles. L'automatisation via cron ou le package logrotate permet de conserver des périodes de rétention cohérentes.

Script init.d

Exemple de script pour /etc/init.d/nginx avec actions start/stop/reload et instructions d'installation au boot via update-rc.d. Pour les distributions modernes, fournir également une unité systemd équivalente afin d'assurer une intégration native au système d'init.

Optimisation pour machines multi‑processeurs

Paramètres clés : worker_processes (typiquement égal au nombre de cœurs) et worker_cpu_affinity pour lier un worker à un cœur. Dimensionnez le nombre de workers en fonction des cœurs physiques et des besoins réseau, puis validez l'affectation CPU avec des outils de monitoring.

worker_processes 4;
worker_cpu_affinity 0001 0010 0100 1000;

Contrôlez l'état des processus avec ps aux | grep nginx et des outils comme top, htop ou des sondes Prometheus pour diagnostiquer les migrations de contexte et optimiser le cache CPU.

Proxy inverse pour Zope/zwook — Cas pratique

Placer un bloc server avec proxy_pass http://localhost:8080/VirtualHostBase/... pour router les requêtes vers Zope, et définir server_name ou utiliser $host pour conserver le domaine d'origine. Le pattern VirtualHostBase permet de mapper précisément les sous-domaines vers l'instance backend ; validez les en-têtes proxys et les timeouts lors des tests charge.

Nginx sous Windows : Installation et Limites

Une version Windows existe pour tests et développement ; les binaires se téléchargent depuis les sources officielles. L'installation implique l'adaptation des chemins de configuration et l'absence des optimisations CPU natives aux noyaux Unix. En production, privilégier Linux pour bénéficier des outils de supervision, de la gestion native des services et des performances optimisées pour les E/S réseau.

Historique et licence de Nginx

Projet initié en 2002 par Igor Sysoev, conçu pour répondre aux problèmes de concurrence et de scalabilité. Le code a été distribué sous licence BSD, fournissant un serveur HTTP libre adapté aux usages industriels. L'architecture événementielle permet d'améliorer la disponibilité et de réduire la latence réseau sur des services à fort trafic.

❓ Foire Aux Questions (FAQ)

Comment dimensionner worker_processes et worker_cpu_affinity pour un serveur 4 cœurs ?

Définir worker_processes 4; et utiliser worker_cpu_affinity 0001 0010 0100 1000; pour attacher chaque worker à un cœur distinct ; cela réduit les migrations de contexte CPU et optimise le cache sur des charges réseau élevées.

Comment configurer Nginx comme reverse proxy pour une instance Zope ?

Placer un bloc server avec proxy_pass http://localhost:8080/VirtualHostBase/... pour router les requêtes vers Zope, et définir server_name ou utiliser $host pour conserver le domaine d'origine. Le PDF contient un exemple complet de mapping des sous-domaines.

Glossaire technique

• Reverse Proxy : serveur intermédiaire qui reçoit les requêtes clients et les achemine vers des serveurs backend pour répartir la charge ou protéger les services internes.
• Terminator SSL : composant qui gère la terminaison TLS/SSL en décryptant le trafic avant transmission au backend, simplifiant la gestion des certificats et la délégation du chiffrement.

Document rédigé par Philippe Lafaye. Le contenu s'appuie sur des pratiques industrielles reconnues et des extraits de configuration éprouvés pour l'exploitation en environnement Linux/Debian.