Cet article est le 3ème dans la série “Migration vers Passenger” qui comprend également :
- le préambule.
- Ruby Entreprise Edition
Le temps de tout mettre en place, j’ai installé Apache (2.2) et je l’ai fait écouter toutes les interfaces sur le port 8080. Ça me permet de tester ma config avant de faire le grand saut.
Nginx reprends un certan nombre de principes d’Apache, comme la notion de fichiers de configuration modulaires (via des include), des virtual hosts, … Lors de ma prise n main de Nginx, j’avais même écrit des scripts facilitant la gestion des virtualhosts en m’inspirant très fortement de ceux d’Apache ; a2ensite, a2dissite, …
J’ai donc une série de virtualhosts, chacun dans un fichier (plus facile à gérer individuellement). La syntaxe de configuration est très différente, mais ce qui doit être configuré chez l’un doit aussi l’être chez l’autre il faut donc “simplement” transposer les directives.
J’ai commencé par une copie toute simple des fichiers de virtualhosts de Nginx dans le dossier /etc/apache2/sites-available (le répertoire standard d’Apache pour les virtualhosts disponibles).
Dans Nginx, il n’y a pas de notion de ServerName puis ServerAlias, c’est tout au même niveau, mais là rien de difficile.
J’ai galéré pendant environ 3 heures inutilement car j’avais pas vu que j’avais gardé le “;” de fin de ligne de Nginx dans la définition des ServerName et ServerAlias dans Apache. Les tests de syntaxe de la config étaient OK, l’analyse des Vhosts actifs et leur ordre semblait aller, … mais bon, c’était aussi stupide que ça. Le plus drôle c’est qu’à chaque fois que je modifiais une config Nginx ces derniers mois, j’oubliais de les mettre ces fichus “;” de fin de ligne.
On définit ensuite les règles de re-écriture (RewriteRule). La syntaxe est là aussi différente mais le principe est identique.
Les règles de compression (Gzip) des contenus se gèrent pour Apache dans chaque site (sauf si j’ai mal vu et qu’on peut aussi le régler globalement) et de manière plus détaillée. Dans Nginx on ne se soucie pas du comportement selon les navigateurs. J’avoue ne pas avoir regardé si il traite ça tout seul en interne ou bien si il ne le traite pas.
Il y a quelques règles d’expiration que je n’ai pas encore adaptées, comme par exemple celle qui indiquent une vie de 1 mois pour tous les contenus graphiques, feuilles de style et javascript.
Il me reste à voir la question des logs.
En soi rien de compliqué ; on indique le niveau du log (”warn” par défaut), le fichier pour les logs d’accès et celui des logs d’erreur.
Par contre le dilemne, c’est la continuité. Le format de logs n’est pas un problème, car j’avais fait écrire à Nginx des logs au format d’Apache (combined), donc rien ne change.
Par contre ils étaient stockés dans /var/log/nginx/neomarco-prod.access.log, … Je vais décemment pas continuer à les stocker ici, mais j’ai quand même besoin d’une homogénéité pour logrotate et webalyzer.
Je pense que je vais simplement les déplacer dans /var/log/apache2/ où Apache continuera de mettre les siens, à moins que vous ayez une meilleure idée.
La fin : épilogue
J’ai ajouté aussi une RewriteRule pour enlever systématiquement les www :