Truedoc

h1. Clusterizzare un'applicazione Django con Nginx

Si suppone di avere un'applicazione django da distribuire su più istanze server, e di volere che il carico sia distribuito fra queste istanze e che anche in caso di malfunzionamento di una o più istanze, il servizio non sia negato, finché almeno un server resta funzionante.

h2. Prerequisiti

* Applicazione Django nella directory @/home/utente/projects/django/myproject/@ (per semplicità la guida assume che l'applicazione sia servita da @./manage.py runserver $PORTA@)

* Nginx

h2. Avvio delle istanze Django

Avviare 4 istanze della stessa applicazione in 4 terminali differenti (un comando per terminale):

<pre>

$ ./manage.py runserver 8000

$ ./manage.py runserver 8001

$ ./manage.py runserver 8002

$ ./manage.py runserver 8003

</pre>

In questo modo si avranno 4 istanze della stessa applicazione, e accedendo con il browser agli indirizzi @127.0.0.1:8000@, @127.0.0.1:8001@, @127.0.0.1:8002@, @127.0.0.1:8003@, si vedrà che ognuna funziona indipendentemente.

h2. Configurazione base di nginx

Si crei il file di configurazione @/etc/nginx/sites-available/cluster@:

<pre>

upstream backend {

    server 127.0.0.1:8000;

    server 127.0.0.1:8001;

    server 127.0.0.1:8002;

    server 127.0.0.1:8003;

}

server {

    listen 80;

    root /home/utente/projects/django/;

    server_name cluster;

    access_log /home/utente/projects/django/access.log;

    error_log /home/utente/projects/django/error.log;

    location / {

        proxy_pass http://backend;

    }

}

</pre>

e si attivi con:

<pre>

# ln -s /etc/nginx/sites-available/cluster /etc/nginx/sites-enabled/cluster

# /etc/init.d/nginx restart

</pre>

In questo modo si dice a nginx di redirigere tutte le richieste che giungono a @http://cluster/@ verso il cluster chiamato @backend@, che è il gruppo di istanze di django.

Perché l'URL @http://cluster@ funzioni però, bisogna aggiungere una riga al file @/etc/hosts@:

<pre>

127.0.0.1 cluster

</pre>

h2. Test

A questo punto si può accedere a @http://cluster/@ e vedere come le richieste vengano divise fra i 4 server, e fermandone alcuni e/o riavviandoli, il sito funziona sempre, a patto che ovviamente almeno un'istanza sia attiva.

Con questa configurazione di base il carico viene distribuito uniformemente fra i componenti del cluster, ma il modulo @upstream@ di nginx supporta diverse opzioni ("documentazione":http://nginx.org/en/docs/http/ngx_http_upstream_module.html), ad esempio @weight@:

<pre>

upstream backend {

    server 127.0.0.1:8000;

    server 127.0.0.1:8001;

    server 127.0.0.1:8002 weight=3;

    server 127.0.0.1:8003;

}

</pre>

in questo modo nginx redirigerà sul terzo server statisticamente il triplo delle richieste rispetto agli altri (può essere utile se uno dei server del cluster ha performance hardware maggiori, o se ha più banda a disposizione), oppure @max_fails@ e @fail_timeout@:

<pre>

upstream backend {

    server 127.0.0.1:8000;

    server 127.0.0.1:8001 max_fails=2 fail_timeout=20s;

    server 127.0.0.1:8002;

    server 127.0.0.1:8003;

}

</pre>

se nginx vedrà negate più di 2 richieste in 20 secondi dal secondo server, lo considererà non disponibile per 20 secondi (i default sono @max_fails=1@ e @fail_timeout=10s@)

<pre>

upstream backend {

    server 127.0.0.1:8000 backup;

    server 127.0.0.1:8001;

    server 127.0.0.1:8002;

    server 127.0.0.1:8003;

}

</pre>

in questo modo il primo server è considerato di backup, e quindi verrà usato solo quando nessun altro server è disponibile.