Chapitre 7.2 — Installer & structurer Nginx

⏱️ TL;DR — On installe Nginx en une commande (sudo apt install nginx), on le pilote comme n’importe quel service systemd (systemctl status/reload/restart nginx), et on grave le réflexe absolu : jamais de reload sans un nginx -t d’abord, qui teste la config et refuse de recharger une conf cassée. On explore ensuite l’arborescence Debian/Ubuntu — nginx.conf, sites-available/ + sites-enabled/ reliés par un lien symbolique, conf.d/, /var/www/, les logs de /var/log/nginx/ — et l’anatomie d’une config : le contexte http contient des server, qui contiennent des location. On écrit un premier server block, et on recharge sans coupure.

🎯 Objectifs

• Installer Nginx et vérifier qu’il tourne.
• Piloter le service : status, reload, restart, et distinguer reload de restart.
• Ancrer le réflexe nginx -t avant tout reload.
• Connaître l’arborescence de config Debian/Ubuntu et le rôle de chaque dossier.
• Lire l’anatomie http → server → location et écrire un premier server block.

Installer Nginx

Sur Ubuntu/Debian, Nginx est dans les dépôts officiels. On rafraîchit l’index puis on installe.

sudo apt update              # rafraîchit la liste des paquets
sudo apt install nginx       # installe Nginx et ses dépendances

L’installation démarre et active déjà le service (il repartira au reboot). Vérifie-le tout de suite.

systemctl status nginx       # doit afficher "active (running)"
curl -I http://localhost     # doit répondre "HTTP/1.1 200 OK" et "Server: nginx"

Si le pare-feu UFW est actif (Partie 5), pense à autoriser le web, sinon rien ne passera de l’extérieur.

sudo ufw allow 'Nginx Full'  # ouvre les ports 80 et 443 (profil fourni par le paquet)
sudo ufw status              # vérifie que 80/443 sont autorisés

🐚 Au terminal — La séquence d’installation complète, à taper d’un bloc : mettre à jour, installer, ouvrir le pare-feu, vérifier. En quatre lignes, Nginx est en façade et joignable.

sudo apt update && sudo apt install nginx
sudo ufw allow 'Nginx Full'
systemctl status nginx
curl -I http://localhost

Piloter le service systemd

Nginx est un service comme les autres (Partie 3). Les commandes que tu utiliseras tous les jours :

systemctl status nginx       # état, PID, dernières lignes de log
sudo systemctl reload nginx  # recharge la config SANS couper les connexions
sudo systemctl restart nginx # arrête puis relance (bref temps d'indisponibilite)
sudo systemctl enable nginx  # démarrage automatique au boot (déjà fait par le paquet)

reload vs restart : la nuance qui compte

• reload demande à Nginx de relire sa config et d’appliquer les changements en douceur : les workers en cours terminent leurs requêtes, de nouveaux workers prennent la nouvelle config. Aucune connexion coupée. C’est ce que tu utilises 99 % du temps après avoir modifié une config.
• restart tue le processus et le relance : il y a une micro-coupure pendant laquelle le port n’écoute pas. Réserve-le aux cas où reload ne suffit pas (par exemple après une mise à jour du binaire).

💡 Réflexe — Après chaque modification de config, le duo gagnant est toujours : sudo nginx -t (tester) puis sudo systemctl reload nginx (appliquer sans coupure). Jamais restart par défaut, jamais reload sans nginx -t avant.

Le réflexe absolu : nginx -t

nginx -t parse toute ta configuration, vérifie la syntaxe et la cohérence, et te dit si elle est valide — sans rien recharger. C’est ta ceinture de sécurité.

sudo nginx -t
# nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
# nginx: configuration file /etc/nginx/nginx.conf test is successful

Si tu as fait une faute (une accolade oubliée, un point-virgule manquant), il te le dit avec le numéro de ligne :

nginx: [emerg] unexpected "}" in /etc/nginx/sites-enabled/formacampus:14
nginx: configuration file /etc/nginx/nginx.conf test failed

⚠️ Piège — Faire sudo systemctl reload nginx sans nginx -t d’abord. Si la config est cassée, le comportement dépend des cas, mais tu risques surtout de te croire à jour alors que Nginx a refusé la nouvelle config (ou pire, de casser le service au prochain restart/reboot, quand plus rien ne rattrapera l’erreur). Toujours nginx -t avant de recharger. C’est le git status de l’admin Nginx : gratuit, systématique, il t’évite les catastrophes.

L’arborescence Debian/Ubuntu

Le paquet Ubuntu/Debian organise la config d’une façon précise qu’il faut connaître (les autres distributions diffèrent un peu). Voici la carte.

/etc/nginx/
├── nginx.conf            # config principale : contexte http, includes globaux
├── sites-available/      # TES configs de sites (un fichier par site), disponibles
│   └── formacampus       # ex. le vhost de FormaCampus
├── sites-enabled/        # les sites ACTIVÉS = liens symboliques vers sites-available
│   └── formacampus -> ../sites-available/formacampus
├── conf.d/               # fragments de config globaux (chargés automatiquement)
├── snippets/             # bouts réutilisables à inclure
├── mime.types           # correspondance extension -> type MIME
/var/www/                 # racine des fichiers servis (statique)
│   └── html/            # site par défaut livré avec le paquet
/var/log/nginx/           # les logs
├── access.log           # chaque requête reçue
└── error.log            # les erreurs (config, 502, permissions...)

Les rôles à retenir :

• nginx.conf : le fichier maître. Il définit le contexte http global (gzip, logs, timeouts par défaut) et surtout inclut les autres : il contient des lignes include qui aspirent conf.d/*.conf et sites-enabled/*.
• sites-available/ : là où tu écris tes configs de site — un fichier par site. Y déposer un fichier ne l’active pas encore.
• sites-enabled/ : les sites réellement chargés. La convention Debian : on n’y copie pas le fichier, on y crée un lien symbolique vers sites-available/. Ainsi la source de vérité reste dans sites-available, et activer/désactiver un site se fait en créant/supprimant un lien — sans toucher au contenu.
• conf.d/ : des fragments globaux chargés automatiquement (utile pour de la config transverse).
• /var/www/ : où vivent les fichiers statiques que Nginx sert (voir chapitre 7.3).
• /var/log/nginx/ : access.log (chaque requête) et error.log (les problèmes) — ton premier réflexe de débogage (chapitre 7.6).

Activer un site : le lien symbolique

Pour activer un site que tu as écrit dans sites-available/, tu crées un lien symbolique dans sites-enabled/ avec ln -s.

# active le site "formacampus"
sudo ln -s /etc/nginx/sites-available/formacampus /etc/nginx/sites-enabled/
sudo nginx -t                 # on teste, TOUJOURS
sudo systemctl reload nginx   # on applique sans coupure
 
# désactiver un site = supprimer le lien (le fichier source reste intact)
sudo rm /etc/nginx/sites-enabled/formacampus

💡 Réflexe — Le paquet installe un site de démonstration default dans sites-enabled/. Sur un vrai serveur, tu le désactives (sudo rm /etc/nginx/sites-enabled/default) une fois ton propre site en place, pour qu’il ne réponde plus à la place du tien sur des requêtes inattendues.

L’anatomie d’une config : http → server → location

La config Nginx est une hiérarchie de contextes (des blocs délimités par { … }). Trois niveaux à connaître :

• Le contexte http (dans nginx.conf) : les réglages globaux du web (gzip, format de logs, timeouts). Il contient tous les server.
• Un contexte server : un site. Il déclare sur quel port on écoute (listen), pour quel nom de domaine (server_name), et où sont les fichiers (root). Il contient des location.
• Un contexte location : que faire pour un chemin d’URL donné (/, /api/, /images/…). C’est là qu’on décide : servir un fichier, ou proxifier vers une app.

Un directive se termine toujours par un point-virgule ; un bloc par des accolades. Voici un premier server block minimal — il sert la racine par défaut sur le port 80, pour n’importe quel nom.

server {
    listen 80;                 # écoute le HTTP sur le port 80
    server_name _;             # "_" = attrape-tout : n'importe quel nom d'hôte
    root /var/www/html;        # dossier racine des fichiers à servir
 
    location / {
        index index.html;      # fichier servi par défaut pour un dossier
    }
}

Que dit ce bloc, ligne à ligne :

• listen 80; — écoute les connexions HTTP sur le port 80.
• server_name _; — le _ est un nom attrape-tout : ce server répond quel que soit le domaine demandé (on affinera au chapitre 7.5).
• root /var/www/html; — la racine : le chemin d’URL est cherché sous ce dossier.
• location / { … } — pour toute URL commençant par / (donc tout), index index.html; désigne le fichier par défaut d’un répertoire.

📚 La doc — Chaque directive Nginx (listen, root, location, try_files…) a une page dédiée sur nginx.org, avec le contexte où elle est valide (http, server, location) et ses valeurs par défaut. Quand tu hésites sur une directive, cherche-la là plutôt que de copier un snippet trouvé au hasard : tu sauras où elle a le droit d’aller et ce qu’elle fait vraiment.

🧭 Sur FormaCampus — L’équipe adopte d’emblée la convention Debian : un fichier par site dans sites-available/ (un pour formacampus.fr, un pour api.formacampus.fr), activé par lien symbolique dans sites-enabled/. Le site default du paquet est supprimé. Chaque modif passe par le rituel sudo nginx -t && sudo systemctl reload nginx — inscrit dans leur checklist de déploiement pour que personne ne recharge une config non testée en pleine journée.

✏️ Exercices

Exercice 1 — Active un site proprement. Tu viens d’écrire /etc/nginx/sites-available/monsite. Donne la séquence exacte de commandes pour l’activer et l’appliquer sans coupure, dans le bon ordre.

sudo ln -s /etc/nginx/sites-available/monsite /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl reload nginx

Exercice 2 — Pourquoi ce message ? Tu tapes sudo systemctl reload nginx et rien ne change sur le site. Tu lances sudo nginx -t et tu obtiens nginx: [emerg] unexpected "}" in .../formacampus:14. Que s’est-il passé, et que corriges-tu ?

🧠 Quiz de révision

Chapitre suivant : Servir du statique — root, try_files, les SPA, le cache des assets et les droits sur /var/www.