Truedoc

Sidebar »

DjangoClusterNginx » Cronologia » Versione 5

Versione 4 (Mark Caglienzi, 13-12-2013 17:50) → Versione 5/6 (Mark Caglienzi, 16-12-2013 16:32)

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 

 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): 

 <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. 

 Oppure, in alternativa, usare Supervisor: Supervisor, [[SupervisorPerDjango|guida a questo link]]. 

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

 <pre> 
 127.0.0.1 cluster 
 </pre> 

 h2. 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":https://docs.djangoproject.com/en/dev/topics/http/sessions/#using-file-based-sessions) 
 * Cookie firmati ("documentazione":https://docs.djangoproject.com/en/dev/topics/http/sessions/#using-cookie-based-sessions) 

 h3. 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@: 

 <pre><code class="python"> 
 SESSION_ENGINE = "django.contrib.sessions.backends.file" 
 SESSION_FILE_PATH = "/home/utente/projects/sessions/" 
 </code></pre> 

 h3. 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: 

 <pre><code class="python"> 
 SESSION_ENGINE = "django.contrib.sessions.backends.signed_cookies" 
 </code></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.