Anatomie d'un serveur web en production — processus, fichiers et configuration réellement chargée

Objectif

Savoir comment nginx et Apache traitent les connexions, où se trouve chaque fichier de configuration, et retrouver la configuration réellement chargée avant de toucher à quoi que ce soit.

L'essentiel

• nginx fonctionne avec un processus maître (lit la configuration, ouvre les ports) et des workers qui traitent chacun des milliers de connexions en parallèle.
• Apache 2.4 choisit un MPM : event (processus + threads, le choix moderne) ou prefork (un processus par connexion, réservé à l'ancien mod_php).
• Le fichier que vous éditez n'est pas forcément celui qui tourne : les include, les liens de sites-enabled et les valeurs par défaut de la distribution s'ajoutent.
• nginx -T affiche toute la configuration chargée, inclusions comprises ; apachectl -S liste les hôtes virtuels réellement actifs.
• On teste toujours (nginx -t, apachectl configtest) puis on recharge (reload), on ne redémarre pas.

1. Ce qui se passe quand un client se connecte

                 ┌───────────────────────────────┐
navigateur ───►  │ processus maître (root)        │  lit nginx.conf, ouvre 80/443
                 │   ├─ worker 1 (www-data)        │  ← accepte et traite les connexions
                 │   ├─ worker 2 (www-data)        │
                 │   └─ worker N (= nb de cœurs)   │
                 └───────────────────────────────┘

Un worker nginx ne bloque jamais sur un client lent : il passe au suivant et revient quand des données arrivent. C'est pour cela qu'un petit serveur nginx tient des dizaines de milliers de connexions ouvertes.

ps -o pid,user,cmd -C nginx
#    PID USER     CMD
#    812 root     nginx: master process /usr/sbin/nginx -g daemon on; master_process on;
#    813 www-data nginx: worker process
#    814 www-data nginx: worker process

Apache avec le MPM event ressemble à ceci : quelques processus, chacun avec des dizaines de threads, et un thread « écouteur » qui garde les connexions keep-alive inactives sans immobiliser un thread de travail.

apachectl -V | grep -i mpm         # Server MPM:     event
apachectl -M | grep mpm            # mpm_event_module (shared)

2. Où sont les fichiers

Sur Debian et Ubuntu, nginx.conf contient ces deux lignes : c'est tout ce qui décide quels sites sont chargés.

include /etc/nginx/conf.d/*.conf;      # seulement les fichiers en .conf
include /etc/nginx/sites-enabled/*;    # tout ce qui est dans le dossier

Conséquence directe : un fichier ancien.conf.bak dans conf.d/ n'est pas chargé, mais un fichier ancien.bak dans sites-enabled/ l'est.

3. Lire la configuration réellement chargée

nginx -t                                   # syntaxe OK ? (lit tous les include)
nginx -T | less                            # tout, fichier par fichier (# configuration file …)
nginx -T 2>/dev/null | grep -n 'server_name'   # quels noms sont servis, et dans quel fichier
nginx -T 2>/dev/null | grep -E '^# configuration file'   # liste des fichiers lus

apachectl configtest                       # Syntax OK
apachectl -S                               # hôtes virtuels, port par port, et le site par défaut
apachectl -t -D DUMP_INCLUDES              # fichiers inclus

Exemple de sortie de apachectl -S :

VirtualHost configuration:
*:80                   is a NameVirtualHost
         default server www.masterlinux.lab (/etc/apache2/sites-enabled/000-default.conf:1)
         port 80 namevhost www.masterlinux.lab (/etc/apache2/sites-enabled/000-default.conf:1)
         port 80 namevhost intranet.masterlinux.lab (/etc/apache2/sites-enabled/intranet.conf:1)

4. Tester, recharger, ne pas couper

nginx -t && systemctl reload nginx          # le maître relit, lance de nouveaux workers,
                                            # les anciens finissent leurs requêtes puis s'arrêtent
apachectl configtest && systemctl reload apache2   # (httpd sur Rocky) : redémarrage « gracieux »

restart coupe toutes les connexions en cours. reload ne les coupe pas. Et si la nouvelle configuration est fausse, reload garde l'ancienne en service : c'est pour cela qu'on teste avant.

5. Cas réel : « j'ai corrigé, mais rien ne change »

À l'agence MasterLinux de Fès, un technicien corrige client_max_body_size dans /etc/nginx/sites-available/intranet… sur une copie intranet.old, car le lien de sites-enabled pointait vers l'autre fichier. Une heure de perdue. Le réflexe qui aurait réglé l'affaire en 10 secondes :

nginx -T 2>/dev/null | grep -n -B2 -A2 client_max_body_size
ls -l /etc/nginx/sites-enabled/

Pièges fréquents

• Éditer le mauvais fichier : vérifiez toujours avec nginx -T ou apachectl -S ce qui est chargé.
• Laisser des sauvegardes dans sites-enabled/ : site.bak y est chargé et crée des doublons de server_name.
• restart au lieu de reload : coupe les téléchargements et les connexions WebSocket en cours.
• Recharger sans tester : sur Apache, une erreur de syntaxe peut empêcher le service de redémarrer au prochain boot.

Lab

nginx n'est pas installé dans votre machine de lab : vous travaillez directement sur une arborescence /etc/nginx préparée, comme si vous lisiez la configuration d'un serveur inconnu. Vous allez :

1. retrouver le fichier qui sert la boutique ;
2. désactiver proprement un site sans perdre sa configuration ;
3. reconstituer à la main ce que nginx -T afficherait, en respectant les règles d'inclusion.

Quiz

1. Quel processus nginx ouvre les ports 80 et 443, et sous quel utilisateur tournent les workers sur Debian ?
2. Un fichier test.conf.old dans conf.d/ est-il chargé ? Et test.old dans sites-enabled/ ?
3. Quelle commande affiche toute la configuration nginx réellement chargée ?
4. Quelle différence entre reload et restart pour les clients connectés ?
5. Quel MPM Apache faut-il préférer avec PHP-FPM ?