infra / nginx

Pourquoi Nginx ?

Leçon 11 exercice

Explication

Un peu d'histoire

Nginx (prononcé "engine-x") est créé par l'ingénieur russe Igor Sysoev, qui commence à l'écrire dès 2002 pour répondre à un problème très concret rencontré chez Rambler, l'un des plus gros portails web russes de l'époque : les serveurs Apache existants s'effondraient face au "problème C10K", la difficulté à gérer dix mille connexions simultanées avec une architecture qui crée un processus ou un thread par connexion. Sysoev publie Nginx en open source en 2004, avec une architecture radicalement différente basée sur des événements plutôt que sur des threads. Le projet devient rapidement un standard de l'industrie, avant qu'une société commerciale, Nginx Inc., ne soit fondée en 2011 puis rachetée par F5 Networks en 2019.

Pourquoi apprendre Nginx aujourd'hui

Nginx fait tourner une part considérable des sites les plus visités au monde et reste, avec Apache et les solutions cloud managées, l'un des piliers de toute infrastructure web moderne. Sur le marché de l'emploi, la maîtrise de Nginx est quasiment incontournable pour un poste DevOps, SRE ou backend senior : c'est l'outil qui se place devant une application pour gérer le HTTPS, répartir la charge entre plusieurs instances, servir les fichiers statiques et absorber une partie des attaques avant même qu'elles n'atteignent le code applicatif. Savoir diagnostiquer un 502 en production ou durcir une configuration TLS est une compétence directement testée en entretien technique infra.

Ce que vous allez apprendre

Comprendre les trois rôles que joue Nginx : serveur web, reverse proxy, load balancer
Voir pourquoi une application ne devrait jamais être exposée directement sur Internet
Comprendre la notion de "seul point d'entrée public" et ce qu'elle apporte en sécurité
Lire une configuration server minimale avec proxy_pass
Te repérer dans la suite du cours, qui construit progressivement une configuration de production complète

Dans quel contexte ?

Une startup vient de déployer sa première API FastAPI avec uvicorn app.main:app --host 0.0.0.0 --port 8000, directement exposée sur Internet. Elle découvre vite les limites de cette approche : pas de TLS natif géré simplement, un seul processus qui encaisse toute la charge, aucune protection contre les pics de trafic, et une adresse de serveur (avec son port) visible de tous. Ajouter Nginx devant cette application règle ces quatre problèmes d'un coup, sans toucher une seule ligne du code Python.

D'abord, le rôle le plus simple : servir des fichiers

Nginx sait servir des fichiers statiques (HTML, CSS, JS, images) directement depuis le disque, sans faire intervenir la moindre application. C'est son rôle historique de "serveur web", hérité d'Apache, et c'est souvent le moyen le plus rapide de livrer du contenu qui ne change pas à chaque requête.

Une fois ce rôle acquis, un second rôle s'ajoute naturellement : le reverse proxy

Un reverse proxy reçoit les requêtes à la place de l'application et les lui transmet en interne, avant de renvoyer la réponse au client. Vu de l'extérieur, seul Nginx existe ; l'application tourne sur un port interne (comme 8000), jamais directement exposé à Internet. C'est ce mécanisme qui permet de gérer le TLS à un seul endroit, indépendamment du langage ou du framework applicatif utilisé derrière.

Rôle de Nginx	Ce qu'il fait	Détaillé dans
Serveur web	Sert des fichiers statiques directement	Leçon sur les fichiers statiques
Reverse proxy	Transmet les requêtes à une application derrière lui	Leçon dédiée à `proxy_pass`
Load balancer	Répartit la charge entre plusieurs instances	Leçon sur `upstream`

Ensuite, un troisième rôle apparaît dès qu'une seule instance ne suffit plus

Quand une application tourne sur plusieurs serveurs ou plusieurs processus pour tenir la charge, Nginx peut répartir les requêtes entre eux : c'est le rôle de load balancer, détaillé dans une leçon dédiée sur les groupes upstream et leurs algorithmes de répartition.

Prérequis

Aucune connaissance de Nginx n'est nécessaire, mais des bases en HTTP (méthodes, ports, headers) et un minimum d'aisance avec le terminal Linux faciliteront grandement la suite du cours.

Piège fréquent

Un débutant confond souvent "avoir Nginx installé" avec "être protégé" : Nginx seul, sans configuration de sécurité (TLS, headers, rate limiting), n'apporte quasiment aucune protection supplémentaire par rapport à une application exposée directement. Toute la valeur vient de la configuration, pas de la simple présence du logiciel.

Maintenant que tu comprends pourquoi Nginx s'intercale devant une application, la prochaine leçon s'attaque au comment : installer Nginx et comprendre la structure de ses fichiers de configuration, avant d'écrire ta première vraie configuration de site.

Commandes & code

Pourquoi Nginx ?

Nginx sert 3 rôles principaux : serveur web (fichiers statiques), reverse proxy (devant une app), et load balancer (répartition de charge).

Architecture typique :

  Internet
     |
     v
 [ Nginx ]  <-- port 80/443, seul point d'entrée exposé
   /   \
  v     v
[App1] [App2]   <-- FastAPI / Node / Django sur des ports internes (8000, 8001...)
  |
  v
[PostgreSQL]    <-- jamais exposé directement à Internet

# Comparaison rapide avec un serveur applicatif nu
# Sans Nginx :
uvicorn app.main:app --host 0.0.0.0 --port 8000   # exposé directement, pas de TLS, pas de cache, 1 process

# Avec Nginx devant :
# - Nginx écoute sur 80/443 (TLS géré ici)
# - Nginx sert les fichiers statiques sans toucher à Python
# - Nginx peut load-balancer vers plusieurs workers uvicorn
# - Nginx protège l'app (rate limiting, headers de sécurité)

# Exemple ultra-minimal : Nginx qui reverse-proxy vers une app FastAPI locale
server {
    listen 80;
    server_name example.com;

    location / {
        proxy_pass http://127.0.0.1:8000;   # transmet la requête à uvicorn
    }
}

Résumé

Nginx = serveur web (statique) + reverse proxy (devant une app) + load balancer (plusieurs instances).
Il devient le SEUL point d'entrée public : les apps derrière lui restent sur des ports internes non exposés.
proxy_pass est la commande centrale du reverse proxy, détaillée dans une leçon dédiée.

Exercices pratiques

1 disponible

Mission : sécuriser une API FastAPI encore exposée directement

Objectif : Diagnostiquer les risques d'une application exposée directement sur Internet et écrire la configuration minimale qui place Nginx en seul point d'entrée.

Contexte

Une jeune startup a lancé son API FastAPI en production avec uvicorn app.main:app --host 0.0.0.0 --port 8000, directement accessible depuis Internet sur le port 8000. Un ami DevOps te demande de justifier pourquoi c'est risqué et d'écrire la configuration Nginx minimale qui corrige ça, avant même de parler de TLS ou de rate limiting.

Résoudre l’exercice →