Web (Apache / Nginx)

Une autre façon d’utiliser PHP-FPM

Salut à tous, le blog de Guillaume n’est pas (encore) complètement mort. Mon nouveau job me prend énormément de temps, plus pleins d’autres chamboulements dans ma vie personnelle font que je n’ai plus une minute à consacrer ni à Sonerezh, ni à mon blog. Deux projets qui me sont pourtant très chers…

J’ai quand même réussi à bloquer quelques heures pour vous écrire cet article un peu plus technique que d’habitude. Et nous allons nous intéresser aux différentes façons qu’il existe d’utiliser PHP-FPM, notamment avec Nginx.

En effet, si vous cherchez sur le web, vous trouverez un grand nombre de sites / blogs qui vous proposeront les mêmes modèles de configuration ou presque, or il faut savoir qu’on peut faire autrement, en fonction de ses besoins ou de l’infrastructure que nous avons à gérer.

Nous allons voir notamment quelles sont les alternatives possibles à pm = dynamic et comment faire pour avoir plusieurs processus PHP-FPM maîtres (ou pères).
(suite…)

Cet article vous a plu ? Partagez-le sur les réseaux sociaux !

Twitter Facebook Google Plus email

Subtilités du cache FastCGI Nginx avec WordPress

Source : nginx.org

Source : nginx.org

J’ai récemment écrit un article récapitulant les différents niveaux de cache offerts par Nginx, et je vous avais notamment parlé du très efficace cache FastCGI. Il s’avère que si vous souhaitez faire fonctionner celui-ci avec PHP-FPM et votre WordPress, il va falloir mettre un peu les mains dans le cambouis…
(suite…)

Cet article vous a plu ? Partagez-le sur les réseaux sociaux !

Twitter Facebook Google Plus email

Compiler et personnaliser Nginx sous Debian

Source : nginx.org

Source : nginx.org

C’est bien connu, Nginx est incapable de charger de nouveaux modules à chaud contrairement à Apache et si vous souhaitez personnaliser votre installation de Nginx avec un module complémentaire de votre cru ou bien un module de la communauté, il va falloir recompiler Nginx à la main. N’ayez pas peur, la compilation n’est pas compliquée en soit, elle nécessite juste un petit peu plus de temps qu’un simple déploiement avec apt…

Avant de vous lancer à corps perdu dans la compilation, sachez que les dépôts Debian proposent plusieurs versions de Nginx contenant différentes options de compilation et différents modules. À vous de voir si ce que vous cherchez n’est pas déjà présent dans les dépôts. D’ailleurs en parlant de dépôt, vous vous apercevrez que ceux de la version stable de Debian 7.x proposent une ancienne version de Nginx. Nous allons donc plutôt utiliser les dépôts « backport source », afin de profiter des dernières fonctionnalités de Nginx.

Le module que je vais installer en complément est un module de limitation de bande passante qui permet d’affecter une bande passante maximale par IP, et non par connexion comme le propose nativement Nginx. Ce module s’intitule nginx_limit_speed_module et les sources sont disponibles sur GitHub.

(suite…)

Cet article vous a plu ? Partagez-le sur les réseaux sociaux !

Twitter Facebook Google Plus email

Gestion des caches avec Nginx et PHP-FPM

Fibre_optique

Les plus curieux d’entre vous auront peut-être remarqué que le blog de Guillaume est propulsé par un WordPress, hébergé sur un serveur HTTP Apache 2. Je me suis récemment mis en tête d’apprendre à utiliser Nginx et d’en découvrir les subtilités afin de migrer tous mes services vers cette plateforme.

Les raisons ?

  1. Apprendre à utiliser Nginx ;
  2. Améliorer les performances du site et des autres services auto-hébergés ;
  3. Alléger la charge serveur car le blog de Guillaume commence à attirer du monde 🙂 Près de 13 000 visites le mois dernier ! Et j’ai de nouveaux projets qui vont arriver…

Je profite donc de mes découvertes pour les noter ici afin de vous en faire profiter. Et aujourd’hui, on va s’attaquer aux différents niveaux de cache que nous allons pouvoir configurer entre Nginx, PHP-FPM et nos clients. En avant donc !

(suite…)

Cet article vous a plu ? Partagez-le sur les réseaux sociaux !

Twitter Facebook Google Plus email

Coloration syntaxique de vos fichiers de configuration Nginx avec Vim

Éditer des fichiers de configurations avec Vim sans coloration syntaxique, c’est moche. Alors voilà comment ajouter un peu de couleurs à votre terminal lorsque vous éditez vos server blocks ou vos fichiers de configuration Nginx.

Le modèle de coloration qui nous intéresse se trouve à cette adresse (prenez la dernière version) et vous pouvez l’enregistrer dans ~/.vim/syntax/.

Ensuite, il faut indiquer à Vim que tous les fichiers présents dans /etc/nginx/ et /usr/local/nginx/conf/ sont des fichiers Nginx qu’il faut mettre en couleur grâce au modèle nginx.vim. Éditez (ou créez) le fichier ~/.vim/filetype.vim pour lui ajouter la ligne suivante :

au BufRead,BufNewFile /etc/nginx/*,/usr/local/nginx/conf/* if &ft == '' | setfiletype nginx | endif

Et normalement vous êtes bons !

Exemple de coloration syntaxique

Oooh les belles couleurs !

Si vous utilisez vim avec sudo, la coloration syntaxique ne fonctionnera pas. Pour qu’elle fonctionne, réitérez l’opération mais avec l’utilisateur root (donc /root/.vim/).

Si jamais la coloration syntaxique n’est pas activée dans Vim, vérifiez que la ligne

syntax on

est bien présente et décommentée dans /etc/vim/vimrc.

Cet article vous a plu ? Partagez-le sur les réseaux sociaux !

Twitter Facebook Google Plus email

Modèle de server-block Nginx pour Monitorix

Accueil Monitorix

Comme je suis en train de migrer tous mes services vers Nginx, j’ai un travail de réécriture de mes hôtes virtuels Apache 2 à faire. Comme j’ai galéré un peu avec Monitorix, voici un petit mémo que je partage avec vous !

Alors évidemment il n’est pas question ici d’installer Monitorix ou Nginx mais seulement du server-block Nginx adapté à l’exécution de Monitorix. Si vous ne savez pas (ou plus) à quoi sert cet outil, je vous en avait vanté les qualités il y a quelques semaines.

Je suppose donc ici que vous avez installé Nginx, Monitorix, que vous souhaitez accéder à son interface à l’adresse http://monitorix.mon-domaine.com et que vous avez désactivé le serveur http embarqué. Voici quelques lignes importantes dans la configuration de Monitorix :

base_dir = /var/lib/monitorix/www/
base_lib = /var/lib/monitorix/
base_url = /
base_cgi = /cgi
 
<httpd_builtin>
        enabled = n
        [...]
</httpd_builtin>
Le problème qui se pose ici, c’est que Nginx n’est normalement pas configuré par défaut pour exécuter des scripts, mais seulement pour transmettre des fichiers statiques. Or Monitorix repose sur l’exécution d’un script CGI (en Perl je crois).

CG quoi ?!

CGI, pour Common Gateway Interface. C’est une interface utilisée par les serveurs HTTP pour exécuter des scripts et récupérer le contenu HTML qu’ils génèrent pour le transférer au client. C’est exactement ce qu’il se passe avec Nginx lorsque vous hébergez un site PHP : Nginx transmet vos requêtes à PHP, PHP génère du HTML que Nginx se charge de vous renvoyer.

Il va donc falloir installer les deux petits paquets suivants, sous Debian, pour que notre serveur HTTP soit en mesure d’exécuter Monitorix :

sudo apt-get install fcgiwrap spawn-fcgi
  • fcgiwrap est un serveur ultraléger, sans configuration, prévu pour fournir un support CGI à Nginx;
  • spawn-fcgi quant à lui est un helper facilitant le démarrage de processus FastCGI (FastCGI étant une évolution de CGI, mais on parle sensiblement de la même chose);

Nginx est donc maintenant prêt à exécuter Monitorix ! Il ne reste plus qu’à préparer la configuration du server block. Je vous propose de l’écrire dans le fichier /etc/nginx/sites-available/monitorix :

server {
        listen 80;
        server_name monitorix.mon-domaine.com;
        root /var/lib/monitorix/www;
        index index.html;
 
        access_log off;
        error_log /var/log/nginx/monitorix-error.log;
 
        location ~ \.cgi$ {
                gzip off;
                fastcgi_pass unix:/var/run/fcgiwrap.socket;
                fastcgi_index monitorix.cgi;
                fastcgi_param   SCRIPT_FILENAME  $document_root$fastcgi_script_name;
                include fastcgi_params;
        }
}
J’ai désactivé les logs d’accès mais vous pouvez très bien les réactiver en renseignant un chemin valide…

Activez votre configuration et rechargez Nginx :

sudo ln -vs /etc/nginx/sites-available/monitorix /etc/nginx/sites-enabled/monitorix
sudo service nginx reload

Et le tour est joué ! http://monitorix.mon-domaine.com devrait vous afficher Monitorix !

Cet article vous a plu ? Partagez-le sur les réseaux sociaux !

Twitter Facebook Google Plus email

Firefox et la mise en cache des redirections 301

La plupart des gens ne s’en rendent pas compte, mais si vous êtes un sysadmin et que vous avez déjà testé des règles de redirections HTTP avec Firefox, vous vous êtes certainement aperçu que le navigateur au panda roux, contrairement à certains de ses concurrents, met en cache toutes les redirections HTTP 301, ou redirections permanentes.

(suite…)

Cet article vous a plu ? Partagez-le sur les réseaux sociaux !

Twitter Facebook Google Plus email

La distribution de contenu avec Nginx et X-Accel

C’est la problématique du jour : comment distribuer du contenu à des utilisateurs tout en ayant la possibilité de limiter la bande passante au cas par cas, en fonction de leur niveau d’abonnement ?

Source : nginx.org

Source : nginx.org

Et oui souvenez-vous : mon projet de fin d’année (qui consiste en une solution dropbox-like) doit proposer différents niveaux d’abonnement aux clients, comprenant différents niveaux de stockage et de bande passante. J’ai mis du temps à chercher une solution pour limiter la bande passante des utilisateurs à la volée car j’avais plusieurs contraintes :

  • Les développeurs refusaient d’implémenter cette fonctionnalité côté code, ce que je comprends tout à fait. Cela n’aurait pas été très propre…
  • Les différents tutoriels proposés sur le web indiquent généralement comment brider la bande passante par IP, or cela ne me suffit pas.
  • Il faut aussi s’assurer que l’utilisateur ne puisse pas modifier sa bande passante. Ce qui impose d’éviter tout mécanisme côté client (au revoir cookies…).

Et après plusieurs mois d’acharnement, c’est finalement Nginx qui m’apporte la solution !

(suite…)

Cet article vous a plu ? Partagez-le sur les réseaux sociaux !

Twitter Facebook Google Plus email

[Apache] Ne pas logguer les accès à /server-status

Ce matin en faisant un petit ménage sur mon serveur, j’ai trouvé qu’Apache me générait un peu plus de logs que d’habitude. Et pour cause…

J’utilise un outil de monitoring dont je vous parlerai prochainement, et cet outil vient consulter la page http://localhost/server-status toutes les minutes ! Du coup, toutes les 60 secondes :

127.0.0.1 - - [06/Nov/2013:12:12:01 +0100] "GET //server-status?auto HTTP/1.1" 200 512 "-" "libwww-perl/6.05"

Cette page générée par mod_status permet aux administrateurs d’avoir un aperçu des performances de leur serveur Apache en temps réel (d’où l’utilisation de cette page par mon outil de monitoring). Il me semble que cette page n’est pas accessible depuis l’extérieur mais seulement depuis localhost. Pour les curieux, la documentation Apache à propos de mod_status est très bien fournie.

C’est bien tout ça, mais tu nous expliques ?

En fait c’est très simple, il suffit d’utiliser le module Apache mod_setenvif qui va nous permettre de définir des variables d’environnement en fonction des attributs de la requête. Bingo, on veut filtrer tout ce qui se termine par "/server-status".

Voyez plutôt la modification à apporter à votre virtual host :

<VirtualHost *:80>
        [...]
 
        # On désactive les logs pour les accès à /server-status
        SetEnvIf Request_URI "^/server-status$" dontlog
        SetEnvIf Request_URI "^$OPT_LB_STATS_URI$" dontlog
 
        ErrorLog ${APACHE_LOG_DIR}/error.log
        CustomLog ${APACHE_LOG_DIR}/access.log combined env=!dontlog
 
        [...]
</VirtualHost>

Tout ce qui contiendra dontlog sera ensuite exclu des logs 🙂

Des bisous !

Cet article vous a plu ? Partagez-le sur les réseaux sociaux !

Twitter Facebook Google Plus email