Come usare Django con Apache e mod_wsgi

Fare il deploy di Django con Apache e mod_wsgi è un modo provato e testato di portare Django in produzione.

mod_wsgi è un modulo Apache che può fare hosting di ogni applicazione Python WSGI, incluso Django. Django funzionerà con ogni versione di Apache che supporta mod_wsgi.

La documentazione ufficiale di mod_wsgi è la fonte di dettagli su come usare mod_wsgi. Probabilmente vorrai iniziare con la documentazione di installazione e configurazione.

Configurazione di base

Una volta che hai installato ed attivato mod_wsgi, modifica il tuo file httpd.conf del server Apache ed aggiungi quanto segue.

WSGIScriptAlias / /path/to/mysite.com/mysite/wsgi.py
WSGIPythonHome /path/to/venv
WSGIPythonPath /path/to/mysite.com

<Directory /path/to/mysite.com/mysite>
<Files wsgi.py>
Require all granted
</Files>
</Directory>

Il primo dato nella riga WSGIScriptAlias è il percorso dell’URL di base in cui vuoi servire la tua applicazione (/ indica l’URL di root) e il secondo è la posizione di un «file WSGI» – vedi sotto – sul tuo sistema, di solito all’interno del pacchetto del tuo progetto (mysite in questo esempio). Questo dice ad Apache di servire qualsiasi richiesta sotto la URL specificata utilizzando l’applicazione WSGI definita in quel file.

Se installi le dipendenze Python del tuo progetto in un virtual environment, aggiungi il percorsi usando WSGIPythonHome. Vedi mod_wsgi virtual environment guide per avere più dettagli.

La linea WSGIPythonPath assicura che il tuo package di progetto sia disponibile per l’importazione sul percorso di Python; in altre parole, che import mysite funzioni.

Il pezzo <Directory> assicura che Apache possa accedere al tuo file wsgi.py.

Successivamente, avremo bisogno di assicurarci che questo wsgi.py con un application object esista. Nella versione Django 1.4, startproject ne creerà uno per te; altrimenti, ne devi creare uno. Vedi la WSGI overview documentation per conoscere il contenuto standard che dovresti mettere in questo file e che altro potresti aggiungere.

Avvertimento

Se più siti Django girano su un singolo processo mod_wsgi, tutti useranno le impostazioni di quello che parte per primo. Questo può essere risolto cambiando:

os.environ.setdefault("DJANGO_SETTINGS_MODULE", "{{ project_name }}.settings")

nel wsgi.py, in:

os.environ["DJANGO_SETTINGS_MODULE"] = "{{ project_name }}.settings"

o usando la modalità demone di mod_wsgi ed assicurandosi che ogni sito giri nel proprio processo demone.

Correggere UnicodeEncodeError per il caricamento di file

If you get a UnicodeEncodeError when uploading or writing files with file names or content that contains non-ASCII characters, make sure Apache is configured to support UTF-8 encoding:

export LANG='en_US.UTF-8'
export LC_ALL='en_US.UTF-8'

Una locazione comune dove mettere questa configurazione è /etc/apache2/envvars.

Alternatively, if you are using mod_wsgi daemon mode you can add lang and locale options to the WSGIDaemonProcess directive:

WSGIDaemonProcess example.com lang='en_US.UTF-8' locale='en_US.UTF-8'

Vedi la sezione Files nella guida di riferimento Unicode per dettagli.

Usare la modalità demone di mod_wsgi

«La modalità demone» è la modalità raccomandata per far girare mod_wsgi (su piattaforme non Windows). Per creare il gruppo del processo demone richiesto e delegare l’istanza di Django per girarvi, dovrai aggiungere le direttive WSGIDaemonProcess e WSGIProcessGroup appropriate. Un ulteriore cambiamento alla configurazione qui sopra se usi la modalità demone è che non puoi usare WSGIPythonPath; invece dovresti usare l’opzione python-path per WSGIDaemonProcess, per esempio:

WSGIDaemonProcess example.com python-home=/path/to/venv python-path=/path/to/mysite.com
WSGIProcessGroup example.com

Se vuoi servire il tuo progetto in una sottodirectory (https://example.com/mysite in questo esempio), puoi aggiungere WSGIScriptAlias alla configurazione qui sopra:

WSGIScriptAlias /mysite /path/to/mysite.com/mysite/wsgi.py process-group=example.com

Vedi la documentazione ufficiale mod_wsgi per dettagli su come approntare la modalità demone.

Distribuire files

Django non distribuisce files direttamente; lascia questo lavoro a qualsiasi web server di tua scelta.

Raccomandiamo di usare un web server separato – per esempio, uno che non sta facendo girare Django – per servire i contenuti multimediali. Ecco alcune buone scelte:

Se, comunque, non hai altra alternativa che servire i file multimediali sullo stesso VirtualHost di Apache di Django, puoi impostare Apache per servire alcune URL come media statici ed altre usando l’interfaccia mod_wsgi per Django.

Questo esempio appronta Django sulla root del sito ma serve robots.txt, favicon.ico, e tutto ciò che si trova nello spazio delle URL /static/ e /media/ come file statico. Tutte le altre URL saranno servite usando mod_wsgi:

Alias /robots.txt /path/to/mysite.com/static/robots.txt
Alias /favicon.ico /path/to/mysite.com/static/favicon.ico

Alias /media/ /path/to/mysite.com/media/
Alias /static/ /path/to/mysite.com/static/

<Directory /path/to/mysite.com/static>
Require all granted
</Directory>

<Directory /path/to/mysite.com/media>
Require all granted
</Directory>

WSGIScriptAlias / /path/to/mysite.com/mysite/wsgi.py

<Directory /path/to/mysite.com/mysite>
<Files wsgi.py>
Require all granted
</Files>
</Directory>

Distribuire i files admin

Quando django.contrib.staticfiles viene settata in INSTALLED_APPS, il server di sviluppo di Django servirà automaticamente i file statici dell’app admin ( e di qualsiasi altra app ). Questo comunque non succede quando usi qualsiasi altra configurazione server. Sei responsabile della configurazione di Apache, o di qualsiasi server tu stia usando, per servire i file di admin.

The admin files live in (django/contrib/admin/static/admin) of the Django distribution.

Noi consigliamo fortemente l’uso di django.contrib.staticfiles  per gestire i file di admin ( insieme a un web server come sottolineato nella sezione precedente; questo significa utilizzare il collectstatic management command per raccogliere tutti i file statici dentro STATIC_ROOT, e poi configurare il tuo web server in modo da servire STATIC_ROOT  su STATIC_URL), ma ecco altri tre approcci:

  1. Crea un link simbolico ai file statici di admin dalla document root (può richiedere +FollowSymLinks nella configurazione di Apache).
  2. Utilizza una direttiva Alias, come mostrato qui sopra, per fare un alias della URL appropriata (probabilmente STATIC_URL + admin/) alla vera locazione dei file di admin.
  3. Copia i file statici di admin in modo che siano presenti nella cartella principale di Apache.

Autenticare da Apache verso il database utenti di Django

Django fornisce un handler per permettere ad Apache di autenticare gli utenti direttamente sul backend di autenticazione Django. Vedi la la documentazione di autenticazione mod_wsgi.

Back to Top