Migrer Apache vers Nginx — les patterns de traduction et le playbook que nous utilisons

Les migrations Apache-vers-Nginx coincent presque toujours au même endroit : .htaccess. Le propriétaire de l'application croit que le fichier fait quelque chose d'irremplaçable. Neuf fois sur dix, c'est une chaîne de RewriteRule qui se traduit en deux lignes de config Nginx. La dixième fois, c'est une règle mod_rewrite si labyrinthique que la réponse plus sûre est de corriger l'application à la place.

C'est la table de traduction, le runbook et la liste de pièges que nous utilisons sur chaque engagement Apache-vers-Nginx.

La table de traduction — les règles qui couvrent 90 % des cas

# Apache: RewriteRule ^(.*)$ /index.php?route=$1 [L]
location / {
  try_files $uri $uri/ /index.php?route=$request_uri;
}
 
# Apache: Order Deny,Allow / Deny from all
location ~ /\.git { deny all; return 404; }
 
# Apache: AuthType Basic / AuthUserFile
location /admin/ {
  auth_basic "restricted";
  auth_basic_user_file /etc/nginx/.htpasswd;
}

.htaccess n'a pas d'équivalent propre dans Nginx — et c'est une feature. La configuration vit en un seul endroit, pas éparpillée dans chaque répertoire de votre webroot.

L'article complet couvre :

• Les patterns mod_rewrite qui mappent directement, et ceux qui nécessitent une refonte
• Le wiring PHP-FPM — le bloc FastCGI que nous copions sur chaque site
• Les quirks de logging Apache vs Nginx (différences de format combined, niveaux de log d'erreur)
• Patterns de sticky-session et d'affinité par cookie en load-balancing
• Le cutover en double-run (Apache sur :8080, Nginx sur :443, traffic façonné à l'edge)
• Le smoke test de 24 heures que nous faisons tourner après cutover avant de déclarer terminé

Contactez-nous si vous aimeriez une seconde paire d'yeux sur la vôtre.