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.

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

Avvio delle istanze Django¶

Innanzitutto assicurarsi che la SECRET_KEY contenuta nei rispettivi file settings.py sia la stessa per tutte le istanze, in modo che i backend di firma digitale e di controllo interni a django funzionino correttamente.

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

$ ./manage.py runserver 8000
$ ./manage.py runserver 8001
$ ./manage.py runserver 8002
$ ./manage.py runserver 8003

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.

Oppure, in alternativa, usare Supervisor: guida a questo link.

Configurazione base di nginx¶

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

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

e si attivi con:

# ln -s /etc/nginx/sites-available/cluster /etc/nginx/sites-enabled/cluster
# /etc/init.d/nginx restart

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 (o configurare il DNS in modo appropriato):

127.0.0.1 cluster

Gestione della session¶

Nel caso dell'esempio, con tutte le istanze in locale e col database condiviso, la sessione di login funziona in modo trasparente dato che django usa la session con database backend. In produzione invece si vorranno cluster formati da più server, e il database potrebbe essere condiviso oppure no, a seconda dell'applicazione specifica. Django mette a disposizione diverse alternative per la gestione della session, ad esempio:

• File (documentazione)
• Cookie firmati (documentazione)

Session backend basato su file¶

Per impostare il file backend bisogna avere una directory raggiungibile e scrivibile da tutti i server che partecipano al cluster, e configurare django in modo che usi quella directory per scrivere i file che contengono i dati di sessione. Come al solito nell'esempio si userà una directory locale, per semplicità, ma in produzione potrebbe essere ad esempio un path remoto montato tramite sshfs. Aggiungere quindi queste due righe al file settings.py:

SESSION_ENGINE = "django.contrib.sessions.backends.file" 
SESSION_FILE_PATH = "/home/utente/projects/sessions/" 

Session backend basato su cookie firmati¶

Django può anche usare cookie per i dati di sessione, firmati usando SECRET_KEY come chiave (che dovrà essere la stessa per tutte le istanze) per evitare che l'utente che accede al sito possa modificarli. In questo modo qualsiasi sia il server che risponde alla singola request, django potrà controllare mediante il cookie firmato se l'utente è loggato oppure no, e tutti gli altri dati di sessione che l'applicazione avrà settato nell'oggetto request.session. Il file settings.py dovrà contenere questa riga:

SESSION_ENGINE = "django.contrib.sessions.backends.signed_cookies" 

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), ad esempio weight:

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

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:

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

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)

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

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