mod_wsgiLink to this heading#Fare il deploy di Django con Apache e mod_wsgi è un modo provato e testato di portare Django in produzione.
\nmod_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.
\nLa documentazione ufficiale di mod_wsgi è la fonte di dettagli su come usare mod_wsgi. Probabilmente vorrai iniziare con la documentazione di installazione e configurazione.
\nUna volta che hai installato ed attivato mod_wsgi, modifica il tuo file httpd.conf del server Apache ed aggiungi quanto segue.
\nWSGIScriptAlias / /path/to/mysite.com/mysite/wsgi.py\nWSGIPythonHome /path/to/venv\nWSGIPythonPath /path/to/mysite.com\n\n<Directory /path/to/mysite.com/mysite>\n<Files wsgi.py>\nRequire all granted\n</Files>\n</Directory>\nIl 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.
mod_wsgiLink to this heading#«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\nWSGIProcessGroup example.com\nSe 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\nVedi la documentazione ufficiale mod_wsgi per dettagli su come approntare la modalità demone.
\nDjango non distribuisce files direttamente; lascia questo lavoro a qualsiasi web server di tua scelta.
\nRaccomandiamo di usare un web server separato – per esempio, uno che non sta facendo girare Django – per servire i contenuti multimediali. Ecco alcune buone scelte:
\n\nSe, 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\nAlias /favicon.ico /path/to/mysite.com/static/favicon.ico\n\nAlias /media/ /path/to/mysite.com/media/\nAlias /static/ /path/to/mysite.com/static/\n\n<Directory /path/to/mysite.com/static>\nRequire all granted\n</Directory>\n\n<Directory /path/to/mysite.com/media>\nRequire all granted\n</Directory>\n\nWSGIScriptAlias / /path/to/mysite.com/mysite/wsgi.py\n\n<Directory /path/to/mysite.com/mysite>\n<Files wsgi.py>\nRequire all granted\n</Files>\n</Directory>\nQuando 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\nDjango distribution.
\nNoi 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 (probabilmente STATIC_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.
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.
\n