# sur django, on met tout dans /static/, donc par habitude je le fais
        # pour tout
        location /static/ {

            # Le dossier doit contenir le dossier 'static'. Par exemple si votre
            # arbo est /home/sametmax/repo/static, le chemin sera
            # /home/sametmax/repo. Rassurez-vous, personne n'aura accès aux
            # autres sous dossiers de "repo".
            root  /chemin/absolu/vers/dossier/;

            # On active la compression
            gzip  on;
            gzip_http_version 1.0;
            gzip_vary on;
            gzip_comp_level 6;
            gzip_proxied any;
            gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript;
            gzip_buffers 16 8k;

            # Sauf pour les vieux nav
            gzip_disable ~@~\MSIE [1-6].(?!.*SV1)~@~];

            # On dit au navigateur de le mettre en cache pour 3 mois. Faites gaffe,
            # mettez un param dans les url de vos balises script/link qui change
            # à chaque version du fichier, sinon vous ne pourrez pas mettre à jour
            # vos fichiers.
            expires modified +90d;
        }

server {
        listen       80;
        server_name allthatcounts.net;

        error_log  /var/log/nginx/error_allthatcounts.log;
        access_log  /var/log/nginx/access_allthatcounts.log;

        location / {
            root /home/allthatcounts/www/;
            gzip  on;
            gzip_http_version 1.0;
            gzip_vary on;
            gzip_comp_level 6;
            gzip_proxied any;
            gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript;
            gzip_buffers 16 8k;
            gzip_disable ~@~\MSIE [1-6].(?!.*SV1)~@~];
            expires modified +90d;
        }
}

En gros c’est juste du log et servir les fichiers statiques compressés avec gzip. Il n’y a rien de plus à faire parce qu’il n’y a pas de backend. Simple. Efficace.

La couille c’est que c’est un copier / coller d’un autre projet que j’ai fais sans trop réfléchir, et quand j’ai mis en prod de nouvelles modifications sur le serveurs, mon Firefox me les affichait pas. Pourtant j’avais bien modifié le manifeste, donc il aurait du tout recharcher…

Sauf que, con de ma race, j’ai copié la ligne :

expires modified +90d;

Qui dit techniquement, met en cache tous les fichiers statiques pour 90 jours. Donc aussi le manifeste. Du coup, toutes les personnes qui ont visité le site ne verront aucune mise à jour pour un bon mois et demi.

Bravo Sam.

Mais c’est vrai que ça aide bien d’avoir sous les yeux les pratiques des autres.

Je ne vais pas expliquer pourquoi Python, je l’ai déjà fait.

Commençons plutôt par la partie purement Web, pour laquelle on utilise Django, le framework Web Python.

Max et moi avons tout deux fait du PHP avant, j’ai tâté des frameworks internes, du Symfony et plus tard du Zope. J’ai regardé du côté de Pyramid et de ses prédécesseurs, et Django est celui qui me plaît le plus. J’ai juste un peu forcé la main à Max :-)

Car oui, le framework a été avant tout un choix de goût.

Ce n’est pas un choix de performances : le framework n’a aucun impact dessus. Aucun. Les architectures ont un impact. Le framework, non. Votre bottleneck sera sur les IO, pas sur le CPU. Le choix de technos asynchrones peut avoir un impact, mais ce n’est pas une question de framework. Tornado, Twisted ou NodeJS, on s’en fout.

Donc Django, essentiellement parce qu’il me plait. Et il me plaît pour ces raisons :

• Il y a un bon équilibre entre découplage et intégration. En général c’est soit très découplé et mal intégré, soit très bien intégré et très couplé.
• C’est bien foutu et bien documenté. Et c’est stable. Vraiment très stable. Les core devs sont hyper sérieux.
• C’est très versatile et ça peut faire plein de trucs out of the box, petits comme gros.
• C’est assez facile à apprendre. Ça reste un framework, donc ce n’est pas la plus simple des démarches, mais dans le royaume des frameworks de cette taille, ça reste vraiment le plus simple.
• La communauté est fantastique : il y a des centaines d’apps qui couvrent pratiquement tous les besoins.
• Et bien entendu, c’est en Python.

En terme de base de données, on a fait du MySQL pendant longtemps. Ça a plutôt bien marché. Maintenant je commence mes nouveaux projets avec PostGres, qui est plus solide. Parfois je fais juste du Sqlite, parce que ça suffit.

Pas de NoSQL. Après plusieurs expériences avec MongoDB et CouchDB, je n’ai pas été convaincu que les bénéfices dépassaient le coût. Il faudrait un article complet là-dessus (qu’on m’a d’ailleurs demandé).

Question OS. c’est du CentOS avec Max (il a plus l’habitude) ou du Ubuntu Server pour mes autres projets. Je reste sur les LTS. Ce n’est pas un choix très réfléchi, c’est surtout par habitude.

Pas de machine virtuelle. On a essayé, sans y trouver un grand intérêt :

• Il faut quand même faire des scripts de migration, donc autant s’en servir pour le déploiement.
• On perd en perfs.
• Les erreurs liées au mal-fonctionnement d’une VM sont absolument indébuggables.
• Si on ne fait pas la VM soit-même, il faut mettre ses couilles dans les mains d’un prestataire de service. J’ai horreur de ça.
• Trouver des gens avec la compétence pour gérer une VM, c’est difficile. Un script de déploiement, c’est du code que tout dev saura déjà lire. Par extension ça veut dire que je m’y replonge facilement des semaines plus tard.

Et donc pour le déploiement, j’utilise fabric, avec fabtools.

Ce n’est pas la solution la plus efficace, d’autant que ça limite à Python 2.7, mais c’est la plus simple. C’est juste du code Python. N’importe qui peut comprendre le déploiement en 15 minutes. Ça se modifie vite, s’adapte facilement.

Il faut comprendre qu’on a jamais plus d’une dizaine de serveurs pour un projet, ces choix sont donc faits en fonction de cela. Il va sans dire que si vous gérez un parc de centaines de machines, ça ne sera pas du tout le même choix technique. Peut être que Chef ou des VM seront alors carrément plus intéressants. Peut être que le NoSQL et sa capacité au scaling sera bien plus rentable.

Il ne s’agit pas de décrier les technos que nous n’utilisons pas. Il s’agit juste de dire, voilà les choix que nous avons faits, dans tel contexte, pour telles (bonnes ou mauvaises) raisons.

Durant les dernières années, on a ajouté Redis à notre stack. C’est un outil fantastique qui sert à tout : de la base de données pour les trucs simples (il y a des fois ou un schéma est overkill) à la solution de caching. C’est ce qu’on a de plus proche du NoSQL.

L’outil est tellement simple à installer (vraiment le degré zero de la maintenance, c’est beau) et à utiliser que ça ne vaut juste pas le coup de s’en priver.

Du coup, plus de memcache. Toutes les grosses requêtes sont sauvegardées dans Redis, dès qu’on fait un script qui a besoin de persistance temporaire, Redis, pour communiquer entre plusieurs process, Redis, pour toutes les opérations qui ont besoin de grosses perfs comme les stats, Redis. Vive Redis.

D’ailleurs on utilise Redis aussi comme broker pour notre gestionnaire de queues et de taches : celery. Si vous pythonez, je vous recommande chaudement celery pour toutes les tâches en background, les crawlers, les chaînes de process, etc.

On a aussi du moteur de recherche. Là on tape dans du Solr (avec haystack). C’est très puissant, en tout cas syntaxiquement car ça ne fait pas de sémantique. Ne vous attendez donc pas à rattraper Google. Mais c’est aussi méga chiant à configurer et très lourd. Je pense qu’un jour on va migrer sur ElasticSearch, mais c’est pas la priorité. Don’t fix what ain’t broken.

Devant tout ça on a Nginx. Comme beaucoup on a fait Apache => Cherokee => lighttp => nginx. Et franchement, je ne reviendrai jamais en arrière : plus léger, plus rapide, plus facile à installer et à configurer, plus versatile. Nginx fait tout, et mieux.

En proxy on a du gunicorn. Parce qu’on avait la flemme de configurer uwsgi et qu’on a pris l’habitude.

Après on utilise plein de libs, de petits outils, etc. Mais ça c’est le gros de notre archi.

Sous Django:

Dans l’Urlconf

urlpatterns = patterns('',
    # return client IP
    url(r'^my_ip$', get_ip),
)

Créez une vue du nom de get_ip qui sera utilisée par l’urlconf

from django import http
 
def get_ip(request):
    """
        Vue qui retourne l'IP du client
    """
    try:

    	# récupère l'ip du client
        return http.HttpResponse(request.META["REMOTE_ADDR"] )

    except Exception, e:
        return http.HttpResponse('error %s' % e)

Le code ci-dessus peut retourner l’adresse locale (127.0.0.1) dans ce cas il faut tester l’existence de la variable HTTP_X_REAL_IP, certains serveurs web ont besoin d’être configuré.

Sous Nginx:

Dans le fichier de configuration de nginx on écrit une nouvelle location

# return client ip
location /my_ip {
    default_type 'text/plain';
    content_by_lua 'ngx.print(ngx.var.remote_addr)';
}

il suffit de se rendre à l’url http://monsite.com/my_ip pour voir s’afficher son ip. Cependant il faut avoir nginx compilé avec le module Lua ce qui peut être délicat si l’on a jamais compilé d’application.

Conclusion:

Si l’on s’en réfère aux deux exemples ci dessus on serait tenté d’utiliser Nginx car en une seule ligne tout le bazar est réglé.
Le hic c’est qu’il faut que Nginx soit compilé avec le module Lua pour afficher l’ip (sauf si quelqu’un connaît une autre façon d’afficher un message de sortie).
La version Django n’est pas fiable à 100% car suivant comment est configuré votre serveur web il se peut que vous vous retrouviez avec une ip du genre 127.0.0.1.
Il y a aussi la possibilité de parser le résultat des sites web cités en tout début d’article, certains proposent des Api je crois mais vous dépendez d’un autre service (on faisait ça au début) qui peuvent vous lâcher à tout moment (ce qui nous est arrivé).
Personnellement je compile toujours nginx avec Lua et quelques autres modules, ça permet de s’affranchir de plus en plus du backend.

PS: j’ai mis à jour le titre car il laissait sous-entendre autre chose (merci à Sébastien)

C’est terrible ça, une vrai maladie. Ça me donne envie de faire des vidéos comme le joueur du Grenier pour râler à voix haute.

Bref.

Donc WSGI a le même but que FastCGI, SCGI, or AJP : c’est une norme qui sert à définir comment un serveur Python et son application peuvent discuter. Ça été pondu pour que tous les serveurs et toutes les applications Python qui respectent la norme soient garantis de pouvoir s’interfacer.

Ça, c’est la définition que vous voyez partout. Super, mais concrètement ça veut dire quoi ?

WSGI, c’est juste une convention de discussion

Un bon dessin vaut mieux…

C'est compliqué de faire un schéma comme ça sérieux ? Ah ça pond une norme de 30 pages mais ça peut pas faire 3 ronds dans paint.

D’un côté vous avez des serveurs comme ceux de cherrypy, de paste, de werkzeug ou comme la commande runserver de Django, ou tels que les serveurs gunicorn, Apache (avec mod_wsgi). Ces logiciels ont pour boulot d’accueillir une requête HTTP et de renvoyer la réponse. Ils ont des problématiques comme : gérer les sockets, gérer plusieurs processus en parallèle, éviter qu’un pirate se balade sur votre serveur, etc.

De l’autre côté vous avez votre application. 9 fois sur 10, votre site Web, donc votre code. Sa problématique c’est de recevoir une requête, la comprendre, et générer une réponse en tapant dans la base de données, et en faisant sa popotte HTML.

Il faut donc que votre serveur dialogue avec votre app, qu’il lui passe la requête, que votre app la gère, retourne la réponse, et file la réponse au serveur. Alors le serveur envoie la réponse au navigateur.

C’est la chose la plus mal expliquée : il y a deux parties à WSGI. Une pour le serveur, et une pour l’application.

Un serveur est dit “compatible WSGI” quand il est capable de transmettre une requête HTTP normale à votre application via le protocole WSGI, et qu’il est capable de récupérer une réponse HTTP depuis votre application via le protocole WSGI pour en faire une requête HTTP normale.

Une application est dite “compatible WSGI” quand elle est capable de recevoir une requête HTTP transformée en un objet Python selon la norme WSGI, et qu’elle retourne une réponse HTTP sous la forme d’un objet Python selon la norme WSGI.

J’avais demandé concrètement, show me the fucking code !

Côté serveur WSGI, on doit lui passer le point d’entrée de votre app.

Le point d’entrée est un module Python qui contient une variable nommé application.

C’est tout.

La variable application doit contenir votre application compatible WSGI.

Une application compatible WSGI a un certain nombre de méthodes pour accepter en paramètres un objet requête HTTP, et retourner un objet réponse HTTP, mais la bonne nouvelle, c’est que vous n’avez absolument pas besoin de savoir comment ça marche.

En effet, tous les frameworks compatibles WSGI (bottle, django, cherrypy, etc) ont une fonction qui retourne cette application toute faite.

Par exemple, avec bottle, mon fichier wsgi va contenir :

from site import app

application = app

C’est tout. app, le décorateur qui permet de faire @app.route('/') dans le code du site bottle, est déjà une application WSGI.

Pour Django, ça va donner un truc comme :

import os
# ont dit quel est le module de settings Django
os.environ["DJANGO_SETTINGS_MODULE"] = "project.settings"

# et on fabrique l'application WSGI avec une fonction
# que Django nous donne
from django.core.wsgi import get_wsgi_application

application = get_wsgi_application()

Le simple fait qu’il y ait une variable nommée application fait que le serveur va se débrouiller. Tout ce qu’il y a à faire, c’est passer en paramètre ce module au serveur, et comment le faire dépend du serveur.

Par exemple pour gunicorn, c’est le premier paramètre de la commande qu’on utilise pour lancer le serveur :

gunicorn nom_du_module

Il faut que le module soit importable (on peut passer l’option --pythonpath pour s’en assurer.)

Pour Apache et mod_wsgi, ça se fait dans le fichier de config apache.conf:

WSGIScriptAlias / /chemin/version/module.wsgi

Bref, faire dialoguer un serveur et une application WSGI, c’est con comme la lune :

1. Faire un module qui contient une variable nommée application contenant l’app WSGI.
2. Dire au serveur où se trouve le fichier

Avantages et inconvénients de WSGI

Parmi les avantages, on retrouve :

• Pas de parsing de la requête au niveau de l’application.
• Entrée de toutes les apps WSGI normalisées.
• Tous les logiciels WSGI sont compatibles entre eux.
• Le module WSGI reste chargé en mémoire une bonne fois pour toute, pas besoin de le recréer à chaque requête.
• WSGI se suffit à lui même pour écrire une application. Dans la théorie, on n’a même pas besoin de framework.

Quant aux inconvénients :

• En pratique il y a très peu de code partagé entre les applications WSGI. La communication sur WSGI s’est très mal passée et cela reste quelque chose de mystérieux pour la plupart des développeurs.
• WSGI ne gère pas les websockets, et la norme est en train d’être mise à jour pour cela. Mais cela prend du temps et les websockets sont déjà là, du coup les gens se tournent vers des solutions non WSGI (tornado, twisted, etc).
• Certains serveurs ne gèrent pas WSGI (comme nginx ou lighttpd), du coup on ne peut pas communiquer directement entre l’app et eux. Il faut un intermédiaire. C’est pour cela qu’on voit très souvent des setups comme nginx <=> gunicorn <=> django, avec un serveur WSGI qui sert d’intermédiaire. Il y a tout de même le bénéfice de pouvoir gérer parfaitement indépendamment le processus WSGI du serveur HTTP, ce qui est très pratique pour le debug, l’administration système, le déploiement, etc.
• WSGI, c’est du Python. Qui dit Python, dit import, qui dit import, dit PYTHON PATH. 90% des erreurs de mise en prod sont des erreurs d’import, et pour cette raison sys.path est presque toujours manipulé dans un fichier qui contient une application WSGI.

Pour la culture

Voici à quoi ressemble un hello world en WSGI :

def application(environ, start_response):
    start_response('200 OK', [('Content-Type', 'text/plain')])
    yield 'Hello World\n'

Et oui, c’est très simple, et il n’y a rien à importer. La norme WSGI est une convention : il doit y avoir une variable nommée application (ici la variable c’est le nom de la fonction), et cette variable doit contenir une application WSGI.

Mais une application WSGI, c’est juste un callable (ici une fonction) qui accepte en paramètres environ (la requête), start_response (une fonction qui écrit l’en-tête de la réponse) et qui retourne un générateur de string. C’est tout.

Il n’y a rien de magique. C’est une simple interface sur laquelle tout le monde s’est mis d’accord.

Quand on fait en Django:

application = get_wsgi_application()

En fait Django ne fait que fabriquer une fonction comme on vient de voir, qui derrière appelle votre application Django.

En revanche, comme on utilise souvent Django derrière nginx, le setup ressemble très souvent à ça :

Quand on voit "socket", ça fait peur, mais c'est juste une ligne de config qui point généralement vers localhost:8000.

Nous allons voir ici une configuration pour un site sous WordPress avec un serveur Nginx, Varnish étant placé en Front c’est à dire devant Nginx (il y a aussi le mode sandwich Nginx / Varnish / Backend).

Installation de Varnish sous ubuntu:

sudo apt-get install varnish

Il y a 2 fichiers qu’il faut retenir pour Varnish, le fichier avec les règles et le fichier de config du service.

Configurer le service, On va faire en sorte que Varnish écoute sur le port 80:

vi /etc/default/varnish

DAEMON_OPTS="-a :80 \
             -T localhost:6082 \
             -f /etc/varnish/default.vcl \
             -S /etc/varnish/secret \
             -s malloc,256m"

Trouvez cette ligne dans le fichier de conf et mettez 80 pour l’option -a.
malloc va sauver le cache en mémoire à hauteur de 256 MB, on peut sauvegarder sur disque si on a un SSD (ex: -s file,/var/lib/varnish/varnish_storage.bin,1G”).

Configurer les règles de cache:

vi /etc/varnish/default.vcl

#
# 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;
}

# 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 ~ "(sametmax.com)")) { 
		set req.backend = default; 
	} else { 
		return (pass); 
	}

	# 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]+", "");

	# Post requests will not be cached
	if (req.http.Authorization || 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);
	}

	# Define the default grace period to serve cached content
	set req.grace = 30s;
	
	# 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);
}
 
# This function is used when a request is sent by our backend (Nginx server)
sub vcl_fetch {
	# Remove some headers we never want to see
	unset beresp.http.Server;
	unset beresp.http.X-Powered-By;

	# For static content strip all backend cookies
	if (req.url ~ "\.(css|js|png|gif|jp(e?)g)|swf|ico") {
		unset beresp.http.cookie;
	}

	# Only allow cookies to be set if we're in admin area
	if (beresp.http.Set-Cookie && req.url !~ "^/wp-(login|admin)") {
        	unset beresp.http.Set-Cookie;
    	}

	# don't cache response to posted requests or those with basic auth
	if ( req.request == "POST" || req.http.Authorization ) {
        	return (hit_for_pass);
    	}
 
    	# don't cache search results
	if ( req.url ~ "\?s=" ){
		return (hit_for_pass);
	}
    
	# only cache status ok
	if ( beresp.status != 200 ) {
		return (hit_for_pass);
	}

	# A TTL of 24h
	set beresp.ttl = 24h;
	
	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;

	# Remove some heanders: Varnish
	unset resp.http.Via;
	unset resp.http.X-Varnish;

	return (deliver);
}
 
sub vcl_init {
 	return (ok);
}
 
sub vcl_fini {
 	return (ok);
}

Avant toute chose voici la doc :) : https://www.varnish-cache.org/docs/3.0/
Ce qu’il faut retenir de ce fichier de règles c’est les parties normalisation, enlever les cookies inutiles (car si cookie alors pas de cache) et ne pas mettre en cache l’admin. Cette config tourne actuellement sur S&M.

Un point intéressant c’est le debug, vous pouvez mettre un set resp.http.X-Cache = “cached”; et vérifier les headers de votre serveur dans le debug de votre navigateur pour savoir si oui ou non la page servie est en cache.

L’admin varnish en ligne de commande:
Varnish possède une admin en ligne de commande où l’on peut par exemple purger le cache d’une ou plusieurs pages.
Tapez varnishadm dans le shell:

varnishadm
200        
-----------------------------
Varnish Cache CLI 1.0
-----------------------------
Linux,3.2.0-25-virtual,x86_64,-smalloc,-smalloc,-hcritbit

Type 'help' for command list.
Type 'quit' to close CLI session.

varnish> ban.url /toto/ma-page.php

Pour purger une page on va utiliser la commande ban.url et y ajouter une partie de l’url à purger. On peut utiliser un ban en appelant également une url de purge avec Curl ou Wget pour les automations, il y a un excellent article sur la purge ici.

Configurer Nginx:
Une fois varnish installé, on va modifier un peu nginx pour que la liaison puisse se faire. Ci-dessous l’exemple de notre conf nginx.

server {
    listen      8080;
    server_name  sametmax.com  ;
    root         /unrep/sametmax/;  # absolute path to your WordPress installation
    index index.php index.html;
    set_real_ip_from        127.0.0.1;
    real_ip_header          X-Forwarded-For;

    location ~ \.php$ {
        include        /etc/nginx/fastcgi_params;
        fastcgi_pass   127.0.0.1:53217;
        fastcgi_index index.php;
        fastcgi_buffers 8 16k;
        fastcgi_buffer_size 32k;
        fastcgi_param  SCRIPT_FILENAME  $document_root$fastcgi_script_name;
    }

Pour PHP on utilise spawn-fcgi que l’on gère avec supervisor dont voici la conf dans /etc/supervisord.conf

[program:php5-cgi]
command=/usr/local/bin/spawn-fcgi -u adolf -n -a 127.0.0.1 -p 53217 -P /tmp/fastcgi-php.pid -F 4 -- /usr/bin/php-cgi
redirect_stderr=true          ; redirect proc stderr to stdout (default false)
user=sametmax
autostart=true
autorestart=true
startsecs=10
startretries=9999999999999
stdout_logfile=/var/log/php5-cgi/php5-cgi.log
stdout_logfile_maxbytes=10MB   ; max # logfile bytes b4 rotation (default 50MB)

Pour résumer:

Dans cette configuration Varnish est en front end et va décider quand servir une page prise dans le cache (disque dur ou RAM) et quand interroger le backend pour servir une nouvelle page.
Sur d’autres sites à fort trafic on a mis Nginx en front end car il encaisse beaucoup plus les hits et qu’il fait très bien le boulot pour servir des pages statiques.

Attention!
Même si Varnish n’est pas compliqué à installer il peut être un vrai casse-tête quand il s’agit de cacher des pages. Pensez donc bien à normaliser vos headers (user-agent, gzip, etc), utilisez le debug.
Bien configuré Varnish vous booste un serveur avec une réélle efficacité, il nous a sauvé 2 sites jusqu’à présent, ça sera d’ailleurs un standard sur nos prochains sites.

Il faut donc être spécifique sur les fichiers à inclure include site.conf ou déplacer nginx.conf dans un autre dossier que celui des sous fichiers de configuration.

cache : le mandataire inverse ou (reverse proxy) peut décharger les serveurs Web de la charge de pages/objets statiques (pages HTML, images) par la gestion d’un cache local. La charge des serveurs Web est ainsi généralement diminuée, on parle alors d’« accélérateur web » ou d’« accélérateur HTTP ».
Intermédiaire de sécurité : le mandataire inverse protège un serveur Web des attaques provenant de l’extérieur. En effet, la couche supplémentaire apportée par les mandataires inverses peut apporter une sécurité supplémentaire. La ré-écriture programmable des URL permet de masquer et de contrôler, par exemple, l’architecture d’un site web interne. Mais cette architecture permet surtout le filtrage en un point unique des accès aux ressources Web.
Chiffrement SSL : le mandataire inverse peut être utilisé en tant que « terminateur SSL », par exemple par le biais de matériel dédié,
Répartition de charge : le mandataire inverse peut distribuer la charge d’un site unique sur plusieurs serveurs Web applicatifs. Selon sa configuration, un travail de ré-écriture d’URL sera donc nécessaire,
Compression : le mandataire inverse peut optimiser la compression du contenu des sites.

Pour résumé:

Visiteur > Web > Votre Serveur > Nginx > Gunicorn > Django

Dans la configuration suivante Nginx va servir les fichiers statiques (images, js, etc) et envoyer le reste des requêtes sur Gunicorn. Gunicorn est une interface WSGI entre le serveur HTTP (nginx) et Python, je n’ai pas trouvé de bonne explication sur WSGI à part le site officiel fait par des autistes.

Soit la configuration de Gunicorn suivante (on peut le lancer avec supervisor):

gunicorn_django  myapp.py --bind 127.0.0.1:8080 --log-file /var/log/myapp.gunicorn.log --log-level info --workers 2 --pid /tmp/myapp.pid  --worker-class gevent

Gunicorn va “écouter” en local sur le port 8080, il va logger des infos dans le fichier /var/log/myapp.gunicorn.log (pratique pour le debug si besoin).
Pour les workers et worker-class regardez la doc.

Configurer Nginx:
Dans la conf Nginx on va avoir.

server {
        listen       80;
        server_name mysite.com www.mysite.com;

        location /static/ {
            root  /home/myapp/prod;
            gzip  on;
        }

        location / {
            proxy_pass http://127.0.0.1:8080; # Pass to Gunicorn
            proxy_set_header X-Real-IP $remote_addr; # get real Client IP
        }
}

location va indiquer à Nginx ce qu’il faut faire lorsqu’il rencontre certaines URL.

Dans notre cas le location /static/ va dire à Nginx de servir directement tous les fichiers du répertoire /home/myapp/prod/static pour les URL http://mysite.com/static/… En général les images, javascript, etc.

Pour le reste location / va renvoyer les requêtes sur votre serveur Gunicorn qui va les traiter.

proxy_set_header sert à passer à Gunicorn certaines infos comme l’IP réelle du client (sinon Gunicorn verrait celle de NGinx 127.0.0.1).

De cette manière on ne surcharge pas Gunicorn pour servir nos fichiers statiques, on ajoute une protection (Nginx).
On peut éventuellement mettre en cache certaines pages mais je n’ai jamais utilisé cette option.
Nginx peut également distribuer la charge sur plusieurs serveurs et se charger de la compression des pages (gzip).

Etape 1: configurer Nginx

Je suppose ici que vous avez une config Django classique avec Nginx qui fait un proxy passe vers un serveur WSGI type cherrypy, gunircorn, uwsgi, etc.

Dans votre fichier de config Nginx, rajoutez ceci:

server {
   ...
   location /secure_upload/{
       internal;
       alias /chemin/absolu/vers/dossier/du/projet/media;
   }
}

La directive internal s’assure qu’une requête extérieur ne peut pas demander d’accéder à cette adresse.

Etape 2: authentifier et rediriger avec une vue Django

Dans cet exemple, on sert uniquement le fichier aux utilisateurs authentifiés. Mais on pourrait très bien le faire sur la saisie d’un code unique, vérifier les droits d’accès, etc. J’ai juste choisi le cas le plus simple.

from django.contrib.auth.decorators import login_required
from django.http import HttpResponse
from django.views import static
from django.conf import settings

@login_required() # on accepte uniquement les requête authentifiées
def serve_secure_static(request, path):

    # en mode debug, on demande à Django de servir le fichier histoire de pas
    # être forcé de setuper nginx sur sa machine de dev
    if settings.DEBUG:
        return static.serve(request, path, settings.SECURE_MEDIA_ROOT)

    # Sinon on retourne une réponse VIDE avec en header le chemin de l'url
    # de l'upload interne
    # Nginx va l'intercepter, réaliser qu'il faut qu'il upload ce qu'il y
    # a à cette URL et faire le reste du boulot
    response = HttpResponse()
    response['X-Accel-Redirect'] = '/secure_upload/%s' % path
    return response

Etape 3 : configurer Django

Evidément il vous faut dans le settings.py:

MEDIA_ROOT = "/chemin/absolu/vers/dossier/du/projet/media"
SECURE_MEDIA_ROOT = os.path.join(MEDIA_ROOT, 'secure')

Les dossiers doivent être créés à la mano.

Et dans urls.py:

url(r'^download/(?P
.*)$', server_secure_static)

Pour savoir si votre version n’est pas désuète vous pouvez en ligne de commande obtenir la version de Nginx que vous possedez ainsi que les paramètres de compilation.

Connaître sa version de Nginx grace à l’option -V:

user@mon_serveur:~# /usr/local/nginx/sbin/nginx -V
nginx version: nginx/1.3.5
built by gcc 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) 
configure arguments: --prefix=/usr/local/nginx --with-http_flv_module --with-http_mp4_module --with-http_secure_link_module