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:
Crea un link simbolico ai file statici di admin dalla document root (può richiedere
+FollowSymLinks
nella configurazione di Apache).Utilizza una direttiva
Alias
, come mostrato qui sopra, per fare un alias della URL appropriata (probabilmenteSTATIC_URL
+admin/
) alla vera locazione dei file di admin.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.