Apache 2.4 : VirtualHost, modules et différences avec Nginx

Apache HTTP Server, ou simplement Apache, est le serveur web libre le plus ancien encore très utilisé : beaucoup d'applications (GLPI, WordPress, Nextcloud, phpMyAdmin) donnent d'abord leur configuration pour lui. Ce chapitre montre comment il est organisé sous Debian, crée un VirtualHost, explique les modules, les MPM et les fichiers .htaccess, puis compare Apache et Nginx pour t'aider à choisir et à justifier ton choix.

Installer Apache et lire son arborescence

Apache et Nginx ne peuvent pas écouter tous les deux sur le port 80 de la même machine. Pour suivre ce chapitre, utilise une VM de test, par exemple un clone de srv-web dans ton laboratoire.

sudo apt install apache2
systemctl status apache2 --no-pager
apache2 -v
# Server version: Apache/2.4.69 (Debian)

Le numéro exact dépend des mises à jour reçues : Debian 13 fournit la branche 2.4, qui reçoit ses correctifs sans changement de comportement.

Debian fournit quatre commandes pour activer et désactiver ces éléments sans manipuler les liens à la main : a2ensite / a2dissite pour les sites, a2enmod / a2dismod pour les modules, a2enconf / a2disconf pour les fragments. Après chacune, Apache doit relire sa configuration.

sudo apachectl configtest      # Syntax OK
sudo systemctl reload apache2

Créer un VirtualHost

Un VirtualHost est l'équivalent Apache d'un server block de Nginx : un site, identifié par son nom et son port. Le même site de recette qu'au chapitre précédent, dans /etc/apache2/sites-available/recette.conf :

<VirtualHost *:80>
    ServerName recette.sorbier-logistique.fr
    DocumentRoot /var/www/recette/public

    <Directory /var/www/recette/public>
        Options -Indexes +FollowSymLinks
        AllowOverride None
        Require ip 192.168.10.208/28 192.168.10.64/26
    </Directory>

    ErrorLog ${APACHE_LOG_DIR}/recette-error.log
    CustomLog ${APACHE_LOG_DIR}/recette-access.log combined
</VirtualHost>

sudo mkdir -p /var/www/recette/public
sudo a2ensite recette
sudo a2dissite 000-default
sudo apachectl configtest && sudo systemctl reload apache2

Comme Nginx, Apache envoie une requête dont le nom ne correspond à aucun ServerName au premier VirtualHost du port, dans l'ordre alphabétique des fichiers de sites-enabled : c'est pour cela que le site par défaut de Debian s'appelle 000-default.conf.

Masquer la version. Le fragment conf-available/security.conf de Debian contient ServerTokens OS et ServerSignature On : les en-têtes et les pages d'erreur annoncent la version d'Apache et le système. Passe-les à ServerTokens Prod et ServerSignature Off.

Les modules

Apache est modulaire : chaque fonction (réécriture d'adresses, TLS, en-têtes, reverse proxy, PHP) est un module qu'on active seulement si l'on en a besoin. Moins de modules, c'est moins de code exposé.

apache2ctl -M        # liste les modules chargés

Les MPM : comment Apache traite les connexions

Le MPM (Multi-Processing Module) décide comment Apache répartit les connexions entre ses processus. Un seul est actif à la fois.

apache2ctl -V | grep MPM
# Server MPM:     event

L'installation du paquet libapache2-mod-php8.4 fait basculer Apache sur prefork. Pour un serveur qui doit tenir la charge, préfère l'MPM event et PHP-FPM, comme avec Nginx :

sudo apt install php8.4-fpm
sudo a2enmod proxy_fcgi setenvif
sudo a2enconf php8.4-fpm
sudo systemctl reload apache2

Le fragment php8.4-fpm.conf envoie tous les fichiers .php au socket de PHP-FPM, /run/php/php8.4-fpm.sock. Le fonctionnement de PHP-FPM est expliqué au chapitre 4.

Les fichiers .htaccess

Un fichier .htaccess placé dans un dossier du site contient des directives Apache qui s'appliquent à ce dossier. Il permet à un développeur de régler des redirections ou une protection sans toucher à la configuration du serveur : c'est le mode de fonctionnement des hébergements mutualisés.

# /var/www/recette/public/.htaccess
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ index.php [QSA,L]

Apache ne lit ces fichiers que si la directive AllowOverride du dossier l'autorise. Sous Debian, apache2.conf règle AllowOverride None pour /var/www/ : un .htaccess est donc ignoré tant que tu n'as pas écrit, dans le VirtualHost, AllowOverride All (tout autoriser) ou une liste précise (AllowOverride FileInfo AuthConfig).

Apache ou Nginx : comment choisir

Dans la pratique, les deux conviennent pour un intranet ou une application de gestion. Choisis selon la documentation de l'application, les compétences de l'équipe et le rôle du serveur. Nginx s'impose quand le serveur sert de reverse proxy ou de répartiteur devant d'autres ; Apache reste naturel quand l'application est livrée avec ses .htaccess. Chez Sorbier, l'équipe a choisi Nginx partout, pour n'avoir qu'un serveur web à maîtriser, à durcir et à superviser. À l'oral, c'est ce genre de justification qu'on attend : un critère lié au contexte, pas « Nginx est plus rapide ».

Exercices

<VirtualHost *:80>
    ServerName intranet.ad.sorbier.example
    ServerAlias intranet
    DocumentRoot /var/www/intranet
    <Directory /var/www/intranet>
        Options -Indexes
        Require ip 192.168.10.0/24
    </Directory>
    ErrorLog ${APACHE_LOG_DIR}/intranet-error.log
    CustomLog ${APACHE_LOG_DIR}/intranet-access.log combined
</VirtualHost>

server {
    listen 80;
    server_name intranet.ad.sorbier.example intranet;
    root /var/www/intranet;
    index index.html;

    allow 192.168.10.0/24;
    deny  all;

    access_log /var/log/nginx/intranet-access.log;
    error_log  /var/log/nginx/intranet-error.log;

    location / {
        try_files $uri $uri/ =404;
    }
}