dans les fichiers de logs de votre serveur Apache, voici une procédure simple pour les supprimer.
On commence par éditer le fichier de configuration /etc/apache2/apache2.conf pour créer un filtre nommé local:
# Filters
SetEnvIf Remote_Addr « 127\.0\.0\.1 » local
SetEnvIf Remote_Addr « \:\:1 » local
Ensuite, on doit activer ce filtre le fichier de définition de votre site (sous le répertoire /etc/apache2/site-enabled). Il faut modifier la ligne suivante:
NGinx est une des alternative au serveur Web Apache (il est actuellement utilisé par plus de 6% des serveurs Web). Il se targue d’être plus rapide, plus léger et facile à configurer.
Nous allons vérifier tout cela dans ce billet en détaillant une installation de NGinx 0.8.54 (Stable) sur une machine GNU/Linux (Ubuntu Desktop 10.10) avec en bonus le support FastCGI de PHP et de Perl !
Installation de NGinx
On commence par ajouter le dépôt officiel pour la version stable:
sudo add-apt-repository ppa:nginx/stable
sudo aptitude update
Puis on installe la bête (facile non ?):
sudo aptitude install nginx
Remarque: si un serveur Web (Apache ou autre) tourne déjà sur votre machine, l’installation de NGinx se passera normalement, par contre il n’arrivera pas à se lancer car le port HTTP par défaut (TCP/80) sera déjà occupé. La solution la plus propre est de configurer NGinx pour qu’il écoute sur un autre port (TCP/81 par exemple) puis faire vos tests en forcant l’utilisation de ce port dans votre navigateur Internet (en ajoutant :81 aux URL). Une fois Nginx validé, il suffira de supprimer l’autre serveur Web de votre machine, puis de reconfigurer Nginx sur le port par défaut (TCP/80).
Premier contact avec NGinx
Un script de démarrage nommé nginx a été installé dans le répertoire /etc/init.d. On peut voir la liste des commandes accepté par ce script en saisissant la ligne de commande suivante:
On ouvre un navigateur sur la même machine puis on entre l’UTL suivante: http://localhost/
La page suivante devrait s’afficher:
On peut ensuite arrêter le serveur:
sudo service nginx stop
Stopping nginx: nginx.
Puis passer à l’étape suivante…
Configuration du serveur NGinx
Les fichiers de configuration se trouvent dans le répertoire /etc/nginx. Les habitués d’Apache ne seront pas trop perturbés par la structure de l’arborescence de ce répertoire:
conf.d/: un répertoire contenant des fichiers de configuration additionnels
sites-available/: répertoire contenant la liste des fichier de configuration des sites disponibles
sites-enabled/: répertoire contenant la liste des fichiers de configuration des sites actifs (liens symboliques vers le répertoire site-availables)
On commence par jeter un coups d’oeil au fichier nginx.conf…. Quel bonheur par rapport à celui d’Apache :).
On passe ensuite au fichier du site par défaut /etc/nginx/sites-available/default (que l’on a activé tout à l’heure par la commande ‘sudo service nginx configtest’):
server {
listen 80
root /usr/share/nginx/www;
index index.html index.htm;
server_name localhost;
location / {
try_files $uri $uri/ /index.html;
}
location /doc {
root /usr/share;
autoindex on;
allow 127.0.0.1;
deny all;
}
location /images {
root /usr/share;
autoindex off;
}
}
On peut donc voir que l’on a un site qui écoute sur le port TCP/80 (listen 80) et sert les pages se trouvant dans le répertoire /usr/share/nginx/www (root /usr/share/nginx/www) à partir de l’URL http://localhost/ (server_name localhost).
Nous allons nous baser sur cet exemple pour construire un nouveau fichier de configuration propre à nos besoins.
On commence par créer l’arborescence qui va héberger nos pages (par exemple /home/labo/www). Si le répertoire n’existe pas il faut le créer et lui donner les bons droits:
mkdir /home/labo/www
Enfin on édite une page de test:
# vi /home/labo/www/index.html
<html><body>Ma page</body></html>
Ensuite on passe à la création du fichier de configuration du site.
sudo vi /etc/nginx/sites-available/monsite
Avec le contenu suivant (à adapter à votre configuration):
# Mon site a moi
server {
listen 80;
root /home/labo/www;
index index.html index.htm;
server_name localhost;
location / {
# First attempt to serve request as file, then
# as directory, then fall back to index.html
try_files $uri $uri/ /index.html;
}
}
On supprime le site par defaut et on active le notre:
cd /etc/nginx/sites-enabled
sudo rm default
sudo ln -s ../sites-available/monsite
On redémarre le serveur Nginx:
sudo service nginx restart
Restarting nginx: nginx.
Puis on teste la page: http://localhost/
Pour rendre le site « visible depuis l’extérieur », il faut changer la ligne:
server_name localhost;
Puis la remplacer par:
server_name www.mondomaine.com;
Il faut bien sur que le nom www.mondomaine.com pointe sur l’adresse IP de votre serveur Nginx…
Test des performances
Pour voir ce qu’il a dans le ventre, j’ai installé en Nginx et Apache sur ma machine. Nginx écoutant sur le port TCP/81 et Apache sur le port TCP/80.
J’ai ensuite utilisé le logiciel httperf (disponible dans les dépôts Ubuntu) pour simuler des requêtes sur le serveur.
On a donc un gain d’environ 30% en terme de requêtes supportées par le serveur.
Request rate / Request number
Support du PHP
De nos jours, un serveur Web sans support PHP c’est un peu comme un Ferrari avec des roues de 13 pouces. Dans l’optique d’avoir un serveur performant nous allons donc utiliser le module externe PHP FPM (PHP FastCGI) qui s’occupera de l’exécution des scripts PHP dans un processus indépendant de NGinx (merci à cet article qui m’a bien aidé).
Par défaut, le processus PHP-FPM va se mettre en écoute sur le port TCP/9000 et écouté les requêtes venant seulement de la machine locale (localhost).
Il ne reste plus qu’à modifier le fichier de configuration de votre site pour prendre en compte le langage PHP (fichier /etc/nginx/sites-available/monsite):
# Mon site a moi
server {
listen 80;
server_name localhost;
root /home/labo/www;
location / {
index index.php index.html;
}
location ~ \.php$ {
fastcgi_pass 127.0.0.1:9000;
include /etc/nginx/fastcgi_params;
fastcgi_index index.php;
}
}
Attention de bien avoir configurer la variable root (« root /home/labo/www » dans mon exemple), sinon vous risquez de tomber sur une erreur 404 lors du passage du script PHP vers le process PHP-FPM.
On relance ensuite Nginx:
sudo service nginx restart
Restarting nginx: nginx.
Pour tester que le PHP fonctionne bien, le plus simple est de créer un fichier info.php (à mettre à la racine du site /home/labo/www/) contenant:
<?php
phpinfo();
?>
Puis de pointer votre navigateur Web vers l’URL: http://localhost/info.php
La page suivante devrait s’afficher:
Support de Perl
Tout comme PHP, nous allons utiliser FastCGI pour exécuter les scripts Perl depuis notre serveur NGinx. Le principe est le même. Un processus (fastcgi-wrapper.pl) va se mettre en écoute sur le port TCP/8999 puis attendre les demandes d’exécution envoyées par NGinx.
Contrairement à PHP, il n’existe pas (encore) de package Ubuntu permettant d’automatiser l’installation de ce processus. Il faut donc mettre un peu les mains dans le cambouis (merci à ce blog) !
On commence par installer le module Perl FCGI sur lequel le processus fastcgi-wrapper.pl va se baser:
sudo perl -MCPAN -e ‘install FCGI’
On installe le processus fastcgi-wrapper.pl qui va s’occuper de l’exécution des scripts Perl:
La plupart des tutos que j’ai trouvé sur le Net utilise ensuite un script init.d pas très beau à voir (http://lindev.fr/public/nginx/perl-fastcgi). En effet, pour arrêter le processus on a droit à un beau killall -9 perl ! Autant dire que si vous avez d’autres processus Perl en tache de fond de votre serveur cela risque de poser quelques problèmes :). J’ai donc écrit un nouveau script basée sur celui du wrapper PHP.
On automatise le lancement de ce script au démarrage du serveur:
Dans ce deuxième billet, nous allons aborder la pierre angulaire de la sécurisation de votre site/blog: la sécurisation du couple infernal Apache/PHP.
Bien qu’il existe d’autres serveurs Web (par exemple le très rapide NGinx ou le très simple Cherokee), Apache reste, à ce jour, le plus répandu. Un des reproche que l’on peut lui faire est sa lourdeur de configuration. Cette lourdeur et l’utilisation de fonctions pas forcement utiles à votre site peut rapidement entraîner des failles de sécurité. Nous allons donc détailler la sécurisation du serveur Web ainsi que celle du moteur de langage PHP qui est utilisé par WordPress.
Je vous rappelle que cet article est découpé en plusieurs billets (vous êtes en train de lire le #2):
Cette série de billets a été co-écrite avec Jérémie Marguerie étudiant à EPITA (merci à lui !).
Serveur Web Apache
Sécuriser l’installation par défaut d’Apache2
Apache est développé en tenant compte de la sécurité mais dévoile, dans le header HTTP, son identité (son nom et son numéro de version) à chaque client qui se connecte. Ne pas divulguer ces informations permet d’éviter aux scripts kiddies de connaitre directement les failles connues pour la version d’Apache utilisée et peut compliquer le travail des crackers.
Pour cacher ces informations aux clients HTTP, il suffit d’éditer le fichier /etc/apache2/conf.d/security et d’y ajouter/modifier les variables suivantes:
ServerTokens Prod
ServerSignature Off
TraceEnable On
Module de securité IDS pour Apache
Il existe dans Apache un module optionnel nommé ModSecurity2 qui permet de détecter et de protéger son serveur contre des attaques touchant vos applications Web (notamment les « SQL injections », « cross-site scripting », « path traversal attacks »…).
On commence par l’installation de mod-secure:
sudo aptitude install libapache2-mod-security2
Par défaut, aucune règle n’est appliquée. Il faut donc partir du fichier de configuration qui est donné en exemple:
# Serial audit log
SecAuditEngine RelevantOnly
SecAuditLogRelevantStatus ^5
SecAuditLogParts ABIFHZ
SecAuditLogType Serial
SecAuditLog /var/log/apache2/modsec_audit.log
# Maximum request body size we will
# accept for buffering
#SecRequestBodyLimit 131072
SecRequestBodyLimit 8192000
# Store up to 128 KB in memory
SecRequestBodyInMemoryLimit 131072
# Buffer response bodies of up to
# 512 KB in length
SecResponseBodyLimit 524288
# Verify that we’ve correctly processed the request body.
# As a rule of thumb, when failing to process a request body
# you should reject the request (when deployed in blocking mode)
# or log a high-severity alert (when deployed in detection-only mode).
SecRule REQBODY_PROCESSOR_ERROR « !@eq 0 » \
« phase:2,t:none,log,deny,msg:’Failed to parse request body.’,severity:2 »
# By default be strict with what we accept in the multipart/form-data
# request body. If the rule below proves to be too strict for your
# environment consider changing it to detection-only. You are encouraged
# _not_ to remove it altogether.
SecRule MULTIPART_STRICT_ERROR « !@eq 0 » \
« phase:2,t:none,log,deny,msg:’Multipart request body \
failed strict validation: \
PE %{REQBODY_PROCESSOR_ERROR}, \
BQ %{MULTIPART_BOUNDARY_QUOTED}, \
BW %{MULTIPART_BOUNDARY_WHITESPACE}, \
DB %{MULTIPART_DATA_BEFORE}, \
DA %{MULTIPART_DATA_AFTER}, \
HF %{MULTIPART_HEADER_FOLDING}, \
LF %{MULTIPART_LF_LINE}, \
SM %{MULTIPART_SEMICOLON_MISSING}, \
IQ %{MULTIPART_INVALID_QUOTING}' »
# Did we see anything that might be a boundary?
SecRule MULTIPART_UNMATCHED_BOUNDARY « !@eq 0 » \
« phase:2,t:none,log,deny,msg:’Multipart parser detected a possible unmatched boundary.' »
On relance ensuite Apache pour prendre en compte le plugin:
sudo /etc/init.d/apache2 restart
Ce module contient un ensemble d’expressions rationnelles dont l’objectif est de bloquer les requêtes jugées dangereuses. Il bloquera une partie des tentatives de piratage. C’est tout de même une barrière de protection faillible mais qui peut empêcher l’exploitation de certaines failles. Dans tout les cas, cela n’empêche pas le développeur de coder correctement, en prenant en compte la sécurité au moment du développement des sites.
Module anti DOS
Nous allons installer le module Apache mod_evasive qui permet d’atténuer les attaques DOS faite en utilisant le protocole HTTP en bloquant les adresses IP des clients trop gourmand, c’est à dire ceux qui demandent trop rapidement des pages webs.
Contrairement à ce que l’on peut lire sur certains sites, ce module ne protège pas des DDOS, seulement des DOS (lire ici une explication des attaques DOS et DDOS). Autrement dit, il bloque les reqêtes venant d’une adresse IP (DOS).
Si un très grand nombre d’IPs font une seule requête : votre serveur sera saturé et le mod_evasive n’aura pas servi (DDOS). Bloquer les DDOS est très difficile car les requêtes sont difficilement reconnaissables des requêtes autorisées.
On commence par installer le module:
sudo aptitude install libapache2-mod-evasive
On édite le fichier /etc/apache2/conf.d/mod-evasive:
C’est la configuration par défaut qui va bloquer pendant 10 secondes (DOSBlockingPeriod) les requêtes HTTP venant de l’adresse IP source si une des assertions suivantes est vérifiée:
il y a plus de 2 requêtes (DOSPageCount) sur la même page dans un intervalle de 1 seconde (DOSPageInterval)
il y a plus de 50 requêtes (DOSSiteCount) sur l’ensemble du site dans un intervalle de 1 seconde (DOSSiteInterval)
On relance ensuite Apache pour prendre en compte le plugin:
sudo /etc/init.d/apache2 restart
Sécurisation du moteur PHP
PHP est un langage interprété, largement utilisé pour générer dynamiquement des pages HTML. C’est le langage utilisé par le moteur de CMS WordPress. La génération des pages de votre blog se faisant directement sur votre serveur, il est important de protéger l’environnement d’exécution des scripts PHP.
Il est donc conseillé d’utiliser suphp. Il est relativement facile à installer et permet d’exécuter vos scripts PHP sous un utilisateur autre que www-data et donc protéger votre système.
Cela permet aussi de servir plusieurs sites internet sur un même serveur. Si un pirate atteint un site, il ne pourra pas toucher aux autres.
Ce module fournit aussi la possibilité de disposer d’un fichier PHP.ini par site web, et offre donc plus de flexibilité que l’installation standard de PHP.
La sécurité a néanmoins un coup: la performance. Attendez vous à des pertes de performances sur vos applications. Dans le cas d’une application codée correctement et d’un serveur non surchargé, cette perte devrait cependant être minime.
Il est également possible de désactiver certaines fonctions sensible de PHP (system, exec…) en éditant le fichier php.ini (voir exemple dans l’étape n°3 de ce billet).
Pour installer suPhp sur votre serveur je vous conseille la lecture de cet article. (si vous voulez/devez faire cohabiter deux versions de PHP, par exemple la 4 et la 5, vous pouvez également consulter ce billet).
Conclusion (temporaire)
On dispose donc maintenant d’un système et d’un serveur Web sécurisé. Il ne reste plus qu’à attendre la suite de cette série de billets pour s’attaquer à la sécurisation du moteur de blogging WordPress.
Varnish est un accélérateur de sites Web fonctionnant sur le principe d’un reverse proxy. Varnish va prendre en charge les requêtes HTTP venant de vos visiteurs et communiquer avec votre serveur Web en ne demandant la création des pages Web seulement quand cela est nécessaire.
Sur un Ubuntu Server (ou une distribution Debian « like »), l’installation se résume à la commande suivante. Vous aurez ainsi la version standard maintenu par les dépôts:
sudo aptitude install varnish
Pour disposer d’une version plus récente et seulement sous Ubuntu, vous pouvez utiliser les lignes de commande suivantes:
Nous allons donc dans un premier temps tester Varnish sur la configuration initiale de notre serveur Web (qui comprend dans mon exemple deux sites virtuels sous Apache). Cette configuration de test permettra de tester les performances de Varnish sans aucun impact sur vos sites (les visiteurs continueront à passer directement par votre serveur Web Apache). Enfin, si les tests sont concluants, nous modifierons la configuration finale pour que vos visiteurs transitent de manière transparente par Varnish.
Configuration de test
Varnish appelle backend les serveurs Web qu’il doit accélérer. Il est possible de définir un ou plusieurs backends par serveur Varnish.
Ainsi, si l’on souhaite accélérer le site https://blog.nicolargo.com qui est hébérgé sur un serveur, il faut saisir la configuration suivante dans le fichier /etc/varnish/default.vcl (configuration librement inspiré de la documentation officielle sur comment optimiser son blog WordPress avec Varnish) avec une gestion du cache sur les requête POST, pas de cache pour la zone admin, gestion des cookies de Google Analytics.
#
# Varnish 3 configuration for WordPress
#
# On Debian OS: /etc/varnish/default.vcl
#
# Nicolas Hennion (aka) Nicolargo
#
# Set the default backend (Nginx server for me)
backend default {
# My Nginx server listen on IP address 127.0.0.1 and TCP port 8080
.host = "127.0.0.1";
.port = "8080";
# Increase guru timeout
# http://vincentfretin.ecreall.com/articles/varnish-guru-meditation-on-timeout
.first_byte_timeout = 300s;
}
# Forbidden IP ACL
acl forbidden {
"41.194.61.2"/32;
"192.54.144.229"/32;
}
# Purge ACL
acl purge {
# Only localhost can purge my cache
"127.0.0.1";
"localhost";
}
# This function is used when a request is send by a HTTP client (Browser)
sub vcl_recv {
# Block the forbidden IP addresse
if (client.ip ~ forbidden) {
error 403 "Forbidden";
}
# Only cache the following sites
#if ((req.http.host ~ "(blog.nicolargo.com)") || (req.http.host ~ "(blogtest.nicolargo.com)")) {
if ((req.http.host ~ "(blog.nicolargo.com)")) {
set req.backend = default;
} else {
return (pass);
}
# Compatibility with Apache format log
if (req.restarts == 0) {
if (req.http.x-forwarded-for) {
set req.http.X-Forwarded-For = req.http.X-Forwarded-For + ", " + client.ip;
} else {
set req.http.X-Forwarded-For = client.ip;
}
}
# Normalize the header, remove the port (in case you're testing this on various TCP ports)
set req.http.Host = regsub(req.http.Host, ":[0-9]+", "");
# Allow purging from ACL
if (req.request == "PURGE") {
# If not allowed then a error 405 is returned
if (!client.ip ~ purge) {
error 405 "This IP is not allowed to send PURGE requests.";
}
# If allowed, do a cache_lookup -> vlc_hit() or vlc_miss()
return (lookup);
}
# Post requests will not be cached
if (req.request == "POST") {
return (pass);
}
# --- WordPress specific configuration
# Did not cache the RSS feed
if (req.url ~ "/feed") {
return (pass);
}
# Blitz hack
if (req.url ~ "/mu-.*") {
return (pass);
}
# Did not cache the admin and login pages
if (req.url ~ "/wp-(login|admin)") {
return (pass);
}
# Remove the "has_js" cookie
set req.http.Cookie = regsuball(req.http.Cookie, "has_js=[^;]+(; )?", "");
# Remove any Google Analytics based cookies
set req.http.Cookie = regsuball(req.http.Cookie, "__utm.=[^;]+(; )?", "");
# Remove the Quant Capital cookies (added by some plugin, all __qca)
set req.http.Cookie = regsuball(req.http.Cookie, "__qc.=[^;]+(; )?", "");
# Remove the wp-settings-1 cookie
set req.http.Cookie = regsuball(req.http.Cookie, "wp-settings-1=[^;]+(; )?", "");
# Remove the wp-settings-time-1 cookie
set req.http.Cookie = regsuball(req.http.Cookie, "wp-settings-time-1=[^;]+(; )?", "");
# Remove the wp test cookie
set req.http.Cookie = regsuball(req.http.Cookie, "wordpress_test_cookie=[^;]+(; )?", "");
# Are there cookies left with only spaces or that are empty?
if (req.http.cookie ~ "^ *$") {
unset req.http.cookie;
}
# Cache the following files extensions
if (req.url ~ "\.(css|js|png|gif|jp(e)?g|swf|ico)") {
unset req.http.cookie;
}
# Normalize Accept-Encoding header and compression
# https://www.varnish-cache.org/docs/3.0/tutorial/vary.html
if (req.http.Accept-Encoding) {
# Do no compress compressed files...
if (req.url ~ "\.(jpg|png|gif|gz|tgz|bz2|tbz|mp3|ogg)$") {
remove req.http.Accept-Encoding;
} elsif (req.http.Accept-Encoding ~ "gzip") {
set req.http.Accept-Encoding = "gzip";
} elsif (req.http.Accept-Encoding ~ "deflate") {
set req.http.Accept-Encoding = "deflate";
} else {
remove req.http.Accept-Encoding;
}
}
# Check the cookies for wordpress-specific items
if (req.http.Cookie ~ "wordpress_" || req.http.Cookie ~ "comment_") {
return (pass);
}
if (!req.http.cookie) {
unset req.http.cookie;
}
# --- End of WordPress specific configuration
# Did not cache HTTP authentication and HTTP Cookie
if (req.http.Authorization || req.http.Cookie) {
# Not cacheable by default
return (pass);
}
# Cache all others requests
return (lookup);
}
sub vcl_pipe {
return (pipe);
}
sub vcl_pass {
return (pass);
}
# The data on which the hashing will take place
sub vcl_hash {
hash_data(req.url);
if (req.http.host) {
hash_data(req.http.host);
} else {
hash_data(server.ip);
}
# If the client supports compression, keep that in a different cache
if (req.http.Accept-Encoding) {
hash_data(req.http.Accept-Encoding);
}
return (hash);
}
sub vcl_hit {
# Allow purges
if (req.request == "PURGE") {
purge;
error 200 "Purged.";
}
return (deliver);
}
sub vcl_miss {
# Allow purges
if (req.request == "PURGE") {
purge;
error 200 "Purged.";
}
return (fetch);
}
# This function is used when a request is sent by our backend (Nginx server)
sub vcl_fetch {
# For static content strip all backend cookies
if (req.url ~ "\.(css|js|png|gif|jp(e?)g)|swf|ico") {
unset beresp.http.cookie;
}
# A TTL of 30 minutes
set beresp.ttl = 1800s;
return (deliver);
}
# The routine when we deliver the HTTP request to the user
# Last chance to modify headers that are sent to the client
sub vcl_deliver {
if (obj.hits > 0) {
set resp.http.X-Cache = "cached";
} else {
set resp.http.x-Cache = "uncached";
}
# Remove some headers: PHP version
unset resp.http.X-Powered-By;
# Remove some headers: Apache version & OS
unset resp.http.Server;
return (deliver);
}
sub vcl_init {
return (ok);
}
sub vcl_fini {
return (ok);
}
Le port d’écoute par défaut de Varnish est TCP/6081 (défini dans le fichier /etc/default/varnish).
Si vous avez un Firewall (iptables) sur votre serveur, il faut penser à ajouter la règle suivante:
iptables -A OUTPUT -p tcp –dport 6081 -j ACCEPT
On relance Varnish pour prendre en compte la configuration:
sudo service varnish restart
Si tout marche bien, vos sites doivent s’afficher avec les URL: http://www.nicolargo.com:6081 et https://blog.nicolargo.com:6081 (à remplacer par vos sites hein, faite pas les boulets…).
Tests sur le site statique
Test local sur le site statique (avec uniquement des éléments statiques page HTML & images). La configuration donnée ci-dessous ne montre pas l’optimisation pour ce site.
Test sur une page statique (HTML simple) sans Varnish:
ab -t 30 -c 5 http://www.nicolargo.com/
Requests per second: 651 [#/sec] (mean)
Time per request: 7.6 [ms] (mean)
Test sur une page statique (HTML simple) avec Varnish:
ab -t 30 -c 5 http://www.nicolargo.com:6081/
Requests per second: 652 [#/sec] (mean)
Time per request: 7.6 [ms] (mean)
Sur notre site Web statique, on n’a donc pas de gain au niveau de la capacité maximale de montée en charge du serveur Apache (Requests per second). Ce qui est normal vu qu’Apache n’a pas grand chose à faire pour servir ce genre de page. Par contre on observe une occupation mémoire moindre pendant le test avec Varnish (environ 10% de moins).
Test sur la page index d’un blog WordPress sans Varnish:
ab -t 30 -c 5 https://blog.nicolargo.com/
Requests per second: 588 [#/sec] (mean)
Time per request: 8.5 [ms] (mean)
Test sur la page index d’un blog WordPress avec Varnish:
ab -t 30 -c 5 https://blog.nicolargo.com:6081/
Requests per second: 3460 [#/sec] (mean)
Time per request: 1.5 [ms] (mean)
Sur notre site dynamique, la valeur ajoutée de Varnish est importante car on a ici un gain de plus de 488% en terme de nombre de requêtes simultanées que votre serveur peut fournir. Sur une page dynamique un peu plus lourde (par exemple un billet avec beaucoup de commentaires), le gain peut alors monter jusqu’à 650%.
Attention, cela ne veut pas dire que votre blog va s’afficher 488% plus vite avec Varnish mais « seulement » que votre serveur pourra accepter 488% de requêtes simultanées maximales en plus.
Configuration finale
Une fois votre site accéléré validé, il faut passer Varnish en production. Les actions suivantes sont à effectuer.
Configurer le serveur Apache hébergeant votre blog pour écouter sur un port différent du port TCP/80 (par exemple TCP/8080). Sous Ubuntu Server, on commence par modifier le fichier /etc/apache2/ports.conf pour lui demander d’écouter les requêtes HTTP sur le port 8080 en lieu et place du port 80:
NameVirtualHost *:8080
Listen 8080
On modifie ensuite le fichier de configuration de nos sites /etc/apache2/site-enabled/virtualhosts: (notez bien la modification du port :8080 et l’utilisation du format de log varnishcombined)
On change ensuite la configuration de Varnish pour pointer les backends vers le port 8080:
backend blog {
.host = « blog.nicolargo.com »;
.port = « 8080 »;
}
La dernière chose à faire si votre serveur est protégé par un Firewall IpTables est de modifier la règle ajoutée dans le premier chapitre de ce billet et d’y ajouter une nouvelle règle pour une éventuelle administration locale de Varnish à l’aide de l’utilitaire varnishadm:
On prend en compte la configuration finale en relancant les deux processus (Apache et Varnish):
sudo service apache2 restart
sudo service varnish restart
A partir de ce moment là, toutes les requêtes HTTP de vos visiteurs seront d’abord prise en compte par Varnish (sur le port TCP/80) puis ensuite, si nécessaire, par votre serveur Apache (TCP/8080).
Ecrire les logs sur le disque
Update du 22/02/2012
Par défaut, Varnish n’écrit pas les logs dans un fichier. Pour forcer Varnish à générer des fichiers de logs au format NSCA dans le sous répertoire /var/log/varnishnsca, nous allons utiliser le daemon VarnishNSCA (installé en même temps que Varnish). Il faut commencer par vérifier que script de lancement du daemon VarnishNSCA (/etc/init.d/varnishnsca) ne contient pas un bug, comme c’est le cas dans ma version 3.0.2:
Remplacer la ligne suivante dans le fichier /etc/init.d/varnishnsca:
DAEMON_OPTS= »-a -w ${LOGFILE} -D -P $PIDFILE} »
par
DAEMON_OPTS= »-a -w ${LOGFILE} -D -P ${PIDFILE} »
Puis forcer le lancement du daemon en modifiant le fichier /etc/default/varnishnsca:
VARNISHNCSA_ENABLED=1
On peut ensuite lancer le daemon:
sudo service varnishnsca start
Il est alors possible d’analyser ce fichier avec vos outils de stats favoris. Par exemple en ligne de commande avec GoAccess:
goaccess -f /var/log/varnish/varnishncsa.log
Quelques commandes utiles
varnishlog: Affichage du log du daemon Varnish.
varnishstat: Affichage des statistiques d’utilisation de Varnish.
varnishhist: Affiche un historique sous forme de graphe des requêtes faites à votre serveur Varnish.
varnishadm: une interface d’administration locale de Varnish
Hier, j’ai passé une grande partie de ma journée dans les aéroports, j’en ai profité pour résumer dans un schéma quelques techniques d’optimisations que l’on peut actuellement mettre en place pour booster son blog.
Depuis que Saint Google prend en compte le temps de chargement des pages dans ses algorithmes, le sujet est devenu très à la mode. Antoine, Jérôme et moi même avont abordé récemment le sujet dans nos blogs respectifs.
J’aimerai que l’on échange sur cette architecture afin que je puisse faire évoluer ce schéma.
Vous pouvez également récupérer le schéma au format Dia.
Lorsque l’on choisi d’héberger son blog WordPress (sur un serveur dédié ou virtuel), la problématique des performances vient assez vite sur le tapis. En effet, l’optimisation du blog permet non seulement de réduire le temps de chargement des pages (et donc d’être bien vu par seigneur gOOgle) mais également de dimensionner au plus juste son serveur: gain de temps d’un coté, gain d’argent de l’autre.
Nous allons donc dans ce billet parcourir une liste non exhaustive de techniques d’optimisations:
ETAPE 1: Hardware
ETAPE 2: Noyau Linux
ETAPE 3: Mise à jour du système d’exploitation
ETAPE 4: MemCached
ETAPE 5: Les modules Apache
ETAPE 6: Configuration d’Apache
ETAPE 7: XCache (PHP)
ETAPE 8: MySQL
ETAPE 9: WP-DBManager
ETAPE 10: W3 Total Cache
ETAPE 11: Thème WordPress
ETAPE 12: Tester/Surveiller
Les commentaires seront bien sur là pour nous faire partager vos solutions !
Le hardware
ETAPE 1) C’est un peu le serpent qui se mort la queue… En effet il est assez difficile de dimensionner le hardware d’un serveur sans avoir fait les optimisations est sans connaitre précisément le trafic du blog (surtout vrai pour les nouveaux blog).
C’est en partie pour ces raisons qui j’ai choisi un serveur VPS de chez Gandi. En effet il est possible d’augmenter ou de diminuer les « parts » affectées à son serveur de manière dynamique (une « part » correspond à une ressource CPU, mémoire et disque).
J’ai actuellement « 3 parts » sur le serveur du Blog de Nicolargo mais je m’en sers également pour d’autres besoins (je pense que pour ce blog, un serveur avec « 2 parts » suffirait largement). Pour une première expérience dans le monde du blogging, un serveur « 1 part » devrait convenir (environ 12€ HT par mois).
Je n’entrerai pas dans les discussions sur le coups relativement élevé de cette solution par rapport à un serveur dédié comme l’offre Dedibox de Online.net.
Le système d’exploitation
L’optimisation du système d’exploitation dépend bien sûr de la distribution Linux utilisée. Lors de la création de mon serveur j’ai choisi d’utiliser Ubuntu Server 8.04 que j’ai fait évolué en 9.04. Pourquoi cette distribution GNU/Linux ? Tout simplement car c’est celle que je connais le plus…
ETAPE 2 ) On commence par optimiser le noyau Linux . Je passe rapidement sur les explications. Il existe de nombreux article sur le net détaillant ces configurations. La configuration donnée est celle de mon serveur VPS (3 parts, 1 Go de RAM), elle doit être adaptée à votre configuration hardware.
Il faut éditer/modifier le fichier /etc/sysctl.conf (disponible sur GitHub):
ETAPE 3)La première chose à faire quand on administre un serveur est bien entendu de le maintenir à jour au niveau des logiciels systèmes et applicatifs. Pour cela je m’aide d’un petit logiciel nommé cron-apt. Ce dernier permet de m’avertir par mail quand une mise à jour est disponible (par exemple une nouvelle version d’Apache ou une librairie PHP). En plus de corriger des failles de sécurités, les mises à jours permettent souvent d’obtenir de meilleures performances (que ce soit en rapidité ou en consommation de ressources).
L’installation est des plus simple:
sudo aptitude install cron-apt
Configuration en éditant le fichier /etc/cron-apt/config, notamment les lignes suivantes:
MAILTO= »nom@domaine.com »
MAILON= »always »
Un mail sera automatiquement envoyé à l’adresse nom@domaine.com, tout les matins à 4:00. Voici un exemple:
On peut voir qu’une mise à jour est disponible. Il ne reste plus qu’a se connecter en SSH sur le serveur et faire un:
sudo aptitude safe-upgrade
Il est possible de faire automatiquement les mises à jour mais je pense cela risqué si quelque chose se passe mal…
On critique souvent les serveurs VPS pour leurs faibles performances disque. Bien que je trouve celle des VPS Gandi plutôt acceptable (environ 6 Mo/s pour l’écriture et 24 Mo/s pour la lecture de petits fichiers type script PHP), il est intéressant de mettre en place un cache mémoire sur notre serveur. Ainsi, les applications compatibles pourront lire et écrire les données en RAM et non plus sur disque.
ETAPE 4) Nous allons donc installer MemCached, un cache mémoire libre. On commence par installer le cache ainsi que la librairie Perl associée (qui sera utilisée par WordPress):
Par défaut, le cache écoute sur l’adresse 127.0.0.1 et sur le port TCP/11211. La taille du cache mémoire est de 64 Mo. J’ai gardé ces paramètres pour mon utilisation.
On peut obtenir des statistiques sur l’utilisation de MemCached en utilisant la commande:
# echo « stats » | nc localhost 11211
STAT pid 2806
STAT uptime 698465
STAT time 1283351366
STAT version 1.2.2
STAT pointer_size 32
STAT rusage_user 31.829989
STAT rusage_system 123.891742
STAT curr_items 12834
STAT total_items 1394993
STAT bytes 48830599
STAT curr_connections 11
STAT total_connections 16845
STAT connection_structures 31
STAT cmd_get 4012823
STAT cmd_set 1394993
STAT get_hits 2547543
STAT get_misses 1465280
STAT evictions 5694
STAT bytes_read 10561103955
STAT bytes_written 37908972470
STAT limit_maxbytes 67108864
STAT threads 1
END
Apache & PHP
On continue ensuite avec l’optimisation du serveur Apache (version 2.xx au moment de l’écriture de ce billet).
ETAPE 5) Apache se base sur un système de modules pour ajouter de nouvelles fonctions à votre serveur Web. Sous Ubuntu Server, la liste des modules actifs se trouvent dans le répertoire /etc/apache2/mods-enabled. Un petit ls dans ce répertoire vous donne donc la liste. L’optimisation consiste à supprimer les modules non utilisés. Je vous conseille la lecture de ce billet qui donne la liste des modules nécessaires au fonctionnement de WordPress. Attention, si votre serveur héberge d’autres sites Web que votre blog, il faut vérifier de ne pas supprimer un module utile…
ETAPE 6) On configure ensuite la manière dont les processus Apache sont lancés et gérés en mémoire et d’autres paramètres. Il faut éditer la section suivante dans le fichier /etc/apache2/apache2.conf (ou httpd.conf sur d’autre distribution GNU/Linux). Pour une description des paramètres, merci de lire le billet suivant:
<IfModule mpm_prefork_module>
StartServers 5
MinSpareServers 5
MaxSpareServers 10
MaxClients 40
MaxRequestsPerChild 2000
</IfModule>
# KeepAlive: Whether or not to allow persistent connections
KeepAlive On
# MaxKeepAliveRequests: The maximum number of requests to allow
MaxKeepAliveRequests 200
# KeepAliveTimeout: Number of seconds to wait for the next request
KeepAliveTimeout 5
# Timeout: The number of seconds before receives and sends time out.
Timeout 50
J’ai également modifier le fichier /etc/apache2/conf.d/optimization pour gagner quelques précieux points aux tests Yslow et Page Speed:
ETAPE 7) WordPress se base sur le langage PHP qui est connu pour être flexible mais pas très performant. C’est pour cela qu’il est nécessaire d’installer un cache PHP sur votre serveur Web WordPress. En gros, il permet de mettre en cache le code PHP déjà compilé. J’utilise personnellement XCache.
L’installation est simple:
sudo aptitude install php5-xcache
On configure ensuite le fichier/etc/php5/conf.d/xcache.ini (à adapter à votre configuration):
Souvent décriée, MySQL reste à l’heure actuelle la base de donnée officielle supportée par le moteur de blogging WordPress. Nous allons donc étudier quelques techniques d’optimisation.
ETAPE 8) On commence par éditer le fichier de configuration /etc/mysql/my.cnf pour ajuster la taille des caches (encore une fois les valeurs sont à adapter en fonction de votre audience/configuration):
query_cache_type = 1
query_cache_limit = 2M
query_cache_size = 32M
ETAPE 9) On installe ensuite le plugin WordPress WP-DBManager. Ce dernier permet de maintenir une base de données optimisée à travers le temps. En plus des fonctions de sauvegarde (manuelle ou automatique) et de restauration de votre base de données WordPress, ce plugin permet de d’optimiser et réparer cette même base.
ETAPE 10)L’installation standard de WordPress (la fameuse installation en 5 minutes) ne tient pas en compte de l’optimisation. Nous allons voir comment configurer l’utilisation parallèle de XCache et Memcached (préalablement installé dans les étapes n°3 et n°5). Pour cela nous allons utiliser l’indispensable plugin W3 Total Cache.
Après l’installation du plugin, il faut se rendre dans le menu Performance > General setting de la page d’administration de WordPress puis cliquer sur le bouton Compatibility check pour vérifier que XCache et Memcached sont bien détectés:
Opcode cache: XCache
Memcache extension: OK
Ensuite on configure WordPress pour utiliser Memcached en activant toutes le fonctions de cache (CDN mis à part) et en utilisant le démon Memcached. Exemple de configuration pour les pages:
Dans le menu Page cache settings j’active toutes les fonctions sauf pour les pages 404:
Dans le menu suivant (Minify settings), j’active toutes les fonctions. Cela à pour but d’optimiser les pages, css et js avant d’être envoyés vers les lecteurs (attention, certains JS n’aiment pas beaucoup ces optimisations, à tester donc…).
Enfin, dans le menu Browser Cache setting, j’active toutes les fonctions et les expires header lifetime à:
3600 secondes pour JS / CSS
3600 secondes pour le HTML
2592000 secondes pour les autres fichiers
A l’heure actuelle, le trafic généré par mon blog ne nécessite pas l’utilisation de caches réseau répartis (CDN). Mais c’est une optimisation à prendre en compte pour les « gros » sites.
ETAPE 11)Rien ne sert d’avoir un kernel Linux, un serveur Web, un moteur PHP et un WordPress optimisés si le thème de votre blog est mal développé. Il est important de tester ce thème et notamment les plugins utilisées. Ces derniers utilisent souvent des JavaScripts qui peuvent pénaliser fortement le temps de chargement de vos pages. Rien de tel que des mesures de type YSlow et Page Speed pour mettre en évidence ce qui ne va pas.
ETAPE 12) Pour tester les optimisations mise en place, j’utilise l’outil GTMetrix qui donne les valeurs YSlow et Page Speed (avec un archivage vous permettant de voir l’évolution des performances de votre blog à travers le temps).
De manière locale et surtout pour valider la configuration de votre serveur Web (Apache dans ce document), vous pouvez utiliser la commande suivante:
ab -t30 -c5 http://blog.mondomaine.com/
La ligne intéressante donnant le nombre maximal de requête par seconde que votre blog peut supporter est la suivante:
Requests per second: 158.19 [#/sec] (mean)
A un niveau plus bas, la commande Linux netstat permet de donner pas mal d’informations sur l’état des sockets:
Enfin, pour surveiller l’activité de MySQL, j’utilise la commande MySqlReport.
Autres optimisations possibles
D’autres optimisations sont possibles, pour vous donner un exemple, je suis tombé l’autre jour sur le première article d’une série en cours sur le blog d’Antoine Benkemoun qui propose d’utiliser Squid pour booster les performances de votre site. C’est une technique très intéressante mais qui nécessite, pour être vraiment efficace, l’utilisation deux deux machines différentes. Une servant de reverse proxy-cache et une autre hébergeant votre blog.
Il est aussi possible de se passer du serveur Web Apache (il est vrai un peu lourd à administrer) pour se pencher vers des serveurs plus légers comme NGinx ou Cherookee. Update: Ou bien d’utiliser NGinx comme serveur Web pour les pages statiques et Apache pour les pages dynamiques (voir exemple de configuration ici). L’avantage d’une telle configuration est un gain non négligeable en terme de consommation mémoire.
Il existe un nombre incalculable d’optimisations possibles, j’espère d’ailleurs en découvrir de nouvelles dans vos commentaires…
Je souhaite faire évoluer mon blog, notamment au niveau du thème. Pour cela, j’hésite encore entre créer mon propre thème (en suivant par exemple le très bon tutorial de Fran6) ou bien en modifiant un thème existant à mes besoins.
Dans les deux cas, j’ai besoin d’un serveur de développement pour installer WordPress avec le nouveau thème. Plusieurs solutions s’offrait à moi:
créer une deuxième arborescence sur mon serveur avec une nouvelle base de donnée WordPress.
utiliser un serveur gratuit (commme mon hébergement chez Free).
héberger un serveur directement sur mon PC.
J’ai donc choisi ce dernier choix pour des raisons de performances et aussi pour me laisser la possibilité de travailler sur ce projet même sans connection internet (si si ca existe encore des zones blanches).
Voici donc un petit tutorial pour installer un serveur de developpement WordPress sous un Mac OS X.
Pour cela, j’ai installé MAMP sur mon Macbook. En deux cliques de souris on installe Apache (avec support PHP 4 ou 5) et MySQL (avec phpMyAdmin).
Lors de l’installation, il faut choisir la version standard et pas la pro:
En allant dans le répertoire d’installation, on a même droit (en cadeau bonux) à un petit Widget pour controler le status des services.
Par la suite, il reste à installer WordPress dans le sous répertoire htdocs (/Applications/MAMP/htdocs) et à configurer le fichier wp-config.php:
...
define('DB_NAME', 'wordpress'); // Le nom de la base de donnees
define('DB_USER', 'root'); // Votre identifiant MySQL
define('DB_PASSWORD', 'root'); // ...et votre mot de passe
define('DB_HOST', 'localhost:8889'); // Dans la plupart des cas, vous n'aurez pas a modifier cette ligne
...
Nous voila donc avec un beau serveur de développement pour tester les nouveaux thèmes et plugins.
A bientôt pour la suite des aventures de Nicolargo à la découverte du thème parfait.
…suite du post sur l’installation de FreeBSD, avec la mise en place d’un serveur Web Apache. Nous partons donc sur l’hypothése ou l’on a un système à jour, non seulement au niveau du noyau mais également au niveau des ports.
On ouvre donc un terminal en root.
Puis on installe Apache (version 2.2.4 au moment de l’écriture de ce post) depuis les ports FreeBSD:
# cd /usr/ports/www/apache22
# make install
… la compilation va prendre un certain temps… bon café…
Une fois la compilation terminé, il faut automatiser le lancement du daemon HTTP au démarrage du serveur. Pour cela il faut ajouter ajouter deux lignes au fichier /etc/rc.conf:
# echo ‘apache22_enable= »YES »‘ >> /etc/rc.conf
Il faut ensuite éditer le fichier /usr/local/etc/apache22/httpd.conf pour le faire coller à votre configuration. Il existe un bon nombre de documentations sur le sujet (par exemple: http://httpd.apache.org/docs/2.2/).
# vi /usr/local/etc/apache22/httpd.conf
Vous pouvez tester si votre installation a marché correctement en lancant le serveur Web:
# apachectl start
Puis en ouvrant un navigateur sur l’URL de votre serveur: http://<@IpDeVotreServeur>. Vous devrier avoir la page suivante qui s’affiche:
Le répertoire racine de votre site Web se trouve: /usr/local/www/apache22/data.
En l’état actuel de la configuration, votre serveur ne prendra pas en compte le language PHP. Il faut pour cela installer le module PHP (version 5) pour Apache. Pour cela:
# cd /usr/ports/lang/php5
# make install
… Ne pas oublier de selectionner « Apache » !!! …
# cd /usr/ports/lang/php5-extensions
# make install
… choisir les extensions voulues …
# cd /usr/local/etc/
# cp php.ini-recommended php.ini
… initialisation des variables…
Il faut ensuite configurer Apache pour qu’il prenne en compte PHP. Pour cela éditer le fichier /usr/local/etc/apache22/httpd.conf:
# vi /usr/local/etc/apache22/httpd.conf
Ajouter dans la section <IfModule mime_module>:
AddType application/x-httpd-php .php
Ajouter dans la section <IfModule dir_module>:
DirectoryIndex index.html, index.php
Il ne reste plus qu’a relancer le serveur Apache:
# apachectl stop
# apachectl start
Voili, vous avez un beau système à jour avec une belle version d’Apache…
A bientôt pour l’installation du serveur FTP…
Varnish
