Så här använder du Django med Apache och mod_wsgi

Att distribuera Django med Apache och mod_wsgi är ett beprövat och testat sätt att få Django i produktion.

mod_wsgi är en Apache-modul som kan vara värd för alla Python WSGI-applikationer, inklusive Django. Django kommer att fungera med alla versioner av Apache som stöder mod_wsgi.

Den ”officiella mod_wsgi-dokumentationen” är din källa till alla detaljer om hur du använder mod_wsgi. Du vill förmodligen börja med installations- och konfigurationsdokumentationen.

Grundläggande konfiguration

När du har installerat och aktiverat mod_wsgi redigerar du Apache-serverns fil httpd.conf och lägger till följande.

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>

Den första delen i WSGIScriptAlias-raden är den bas-URL-sökväg som du vill använda för din applikation (/ anger rot-URL), och den andra delen är platsen för en ”WSGI-fil” - se nedan - på ditt system, vanligtvis inuti ditt projektpaket (mysite i det här exemplet). Detta säger till Apache att servera alla förfrågningar under den angivna URL:en med hjälp av WSGI-applikationen som definieras i den filen.

Om du installerar ditt projekts Python-beroenden i en virtuell miljö, lägg till sökvägen med hjälp av WSGIPythonHome. Se guiden för virtuell miljö mod_wsgi virtual environment guide för mer information.

Raden WSGIPythonPath säkerställer att ditt projektpaket är tillgängligt för import på Python-sökvägen; med andra ord, att import mysite fungerar.

Delen <Directory> säkerställer att Apache kan komma åt din fil wsgi.py.

Därefter måste vi se till att denna wsgi.py med ett WSGI-applikationsobjekt finns. Från och med Django version 1.4 kommer startproject att ha skapat ett åt dig; annars måste du skapa det. Se WSGI overview documentation för standardinnehållet som du bör lägga till i den här filen och vad du kan lägga till i den.

Varning

Om flera Django-webbplatser körs i en enda mod_wsgi-process kommer alla att använda inställningarna för den som råkar köras först. Detta kan lösas genom att ändra:

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

i wsgi.py, till:

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

eller genom att använda mod_wsgi daemon-läge och se till att varje webbplats körs i sin egen daemon-process.

Åtgärdar UnicodeEncodeError för filuppladdningar

Om du får ett UnicodeEncodeError när du laddar upp eller skriver filer med filnamn eller innehåll som innehåller icke-ASCII-tecken, kontrollera att Apache är konfigurerat för att stödja UTF-8-kodning:

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

En vanlig plats att placera denna konfiguration på är /etc/apache2/envvars.

Alternativt, om du använder daemonläget mod_wsgi kan du lägga till alternativen lang och locale i direktivet WSGIDaemonProcess:

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

Se avsnittet Filer i Unicode-referensguiden för mer information.

Använda mod_wsgi daemonläge

”Daemon-läge” är det rekommenderade läget för att köra mod_wsgi (på plattformar som inte är Windows). För att skapa den nödvändiga daemonprocessgruppen och delegera Django-instansen att köras i den, måste du lägga till lämpliga WSGIDaemonProcess och WSGIProcessGroup-direktiv. En ytterligare ändring som krävs i ovanstående konfiguration om du använder daemonläge är att du inte kan använda WSGIPythonPath; istället bör du använda alternativet python-path till WSGIDaemonProcess, till exempel:

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

Om du vill servera ditt projekt i en underkatalog (https://example.com/mysite i det här exemplet) kan du lägga till WSGIScriptAlias i konfigurationen ovan:

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

Se den officiella dokumentationen för mod_wsgi för mer information om hur du ställer in daemonläget.

Servering av filer

Django serverar inte filer själv, utan överlåter det jobbet till den webbserver du väljer.

Vi rekommenderar att du använder en separat webbserver - dvs. en som inte också kör Django - för att servera media. Här är några bra val:

• Nginx

• En avskalad version av Apache

Om du däremot inte har något annat val än att servera mediefiler på samma Apache VirtualHost som Django, kan du ställa in Apache så att vissa webbadresser serveras som statisk media och andra med hjälp av mod_wsgi-gränssnittet till Django.

Detta exempel konfigurerar Django vid webbplatsens rot, men serverar robots.txt, favicon.ico och allt i URL-utrymmena /static/ och /media/ som en statisk fil. Alla andra webbadresser kommer att serveras med 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>

Servering av adminfilerna

När django.contrib.staticfiles är i INSTALLED_APPS, serverar Django-utvecklingsservern automatiskt de statiska filerna för admin-appen (och alla andra installerade appar). Detta är dock inte fallet när du använder något annat serverarrangemang. Du är ansvarig för att ställa in Apache, eller vilken webbserver du än använder, för att servera adminfilerna.

Administratörsfilerna finns i (django/contrib/admin/static/admin) i Django-distributionen.

Vi rekommenderar starkt att du använder django.contrib.staticfiles för att hantera adminfilerna (tillsammans med en webbserver enligt beskrivningen i föregående avsnitt; detta innebär att du använder hanteringskommandot collectstatic för att samla in de statiska filerna i STATIC_ROOT och sedan konfigurerar din webbserver för att servera STATIC_ROOT på STATIC_URL), men här är tre andra tillvägagångssätt:

1. Skapa en symbolisk länk till de statiska admin-filerna från dokumentroten (detta kan kräva +FollowSymLinks i din Apache-konfiguration).

2. Använd ett Alias-direktiv, som visas ovan, för att aliasera den lämpliga URL:en (förmodligen STATIC_URL + admin/) till den faktiska platsen för adminfilerna.

3. Kopiera de statiska filerna för admin så att de hamnar i Apache-dokumentroten.

Autentisering mot Djangos användardatabas från Apache

Django tillhandahåller en hanterare som gör det möjligt för Apache att autentisera användare direkt mot Djangos autentiseringsbackends. Se mod_wsgi autentiseringsdokumentation.