mod_wsgiLink to this heading#Att distribuera Django med Apache och mod_wsgi är ett beprövat och testat sätt att få Django i produktion.
\nmod_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.
\nDen ”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.
\nNär du har installerat och aktiverat mod_wsgi redigerar du Apache-serverns fil httpd.conf och lägger till följande.
\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>\nDen 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.
mod_wsgi daemonlägeLink to this heading#”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\nWSGIProcessGroup example.com\nOm 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\nSe den officiella dokumentationen för mod_wsgi för mer information om hur du ställer in daemonläget.
\nDjango serverar inte filer själv, utan överlåter det jobbet till den webbserver du väljer.
\nVi 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:
\n\nOm 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\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>\nNä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.
\nVi 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:
Skapa en symbolisk länk till de statiska admin-filerna från dokumentroten (detta kan kräva +FollowSymLinks i din Apache-konfiguration).
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.
Kopiera de statiska filerna för admin så att de hamnar i Apache-dokumentroten.
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.
\n