Django pozwala w przyjemny sposób tworzyć treści webowe, które niemal natychmiast możemy podejrzeć w oknie przeglądarki. Gdy tworzymy, mając ustawienia w settings.py jako

DEBUG = True
po wykonaniu:

$ python manage.py runserver
Performing system checks...

System check identified no issues (0 silenced).
August 07, 2018 - 16:40:12
Django version 1.11.14, using settings 'duser.settings'
Starting development server at http://127.0.0.1:8000/
Quit the server with CONTROL-C.

wynik jest widoczny pod lokalnym adresem przeglądarki 127.0.0.1 / localhost i na porcie domyślnym 8000.

Jednak gdy zmienimy DEBUG na False, czyli tryb produkcyjny, i uruchomimy ‚runserver’ -… uzyskany wynik ędzie zazwyczaj odbiegał od wcześniejszych oczekiwań… Będzie pozbawiony plików statycznych – JavaScript, CSS oraz obrazów.

Poniżej opiszę swoje doświadczenia z uruchamiania Djangowej apki pod Apache2/Django (WSGI) oraz za pomocą uWSGI (na serwerze Linux). Opiszę to tak jak sam (nie)rozumiem 🙂

Różnice będą dotyczyć plików:

settings.py, urls.py, plików konfiguracji Apache2 / sposobu uruchamiania w uWSGI.

A więc do dzieła.

Apache2/WSGI

na serwerze z Apache2 pod Django (z takim miałem najwięcej doświadczeń), każda zmiana w plikach Django (prócz plików statycznych i templatek) będzie wymagała restartu serwera:

service apache2 restart

wynika stąd, że uruchamianiem zajmuje się server Apache2 i korzysta w nim z pliku konfiguracyjnego przygotowanego w

/etc/apache2/conf-available

Apache musi mieć zainstalowany:

sudo apt-get install libapache2-mod-wsgi

Jak przygotować plik konfiguracyjny dla Apache2?

sudo nano /etc/apache2/sites-available/wsgi_manage.conf

i wpisujemy:

<VirtualHost *:80>
ServerName pogoda.wiks.eu

ServerAdmin webmaster@localhost

ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined

# /manage/static/admin /img/icon-addlink.svg
Alias /manage/static/admin /usr/local/lib/python2.7/dist-packages/django/contrib/admin/static/admin
<Directory /usr/local/lib/python2.7/dist-packages/django/contrib/admin/static/admin>
Require all granted
</Directory>

Alias /manage/static /home/wiks/projects/duser/app/static
<Directory /home/wiks/projects/duser/app/static>
Require all granted
</Directory>

<Directory /home/wiks/projects/duser>
<Files wsgi.py>
Require all granted
</Files>
</Directory>

WSGIDaemonProcess proj_manage python-path=/usr/local/lib/python2.7/dist-packages
WSGIProcessGroup proj_manage
WSGIScriptAlias /manage /home/wiks/projects/duser/duser/wsgi.py

</VirtualHost>

W moim wypadku skorzystałem z edytora nano dla Debiana.

Jak rozumiem zapisy w tym pliku?

<VirtualHost *:80>  i ServerName pogoda.wiks.eu

czyli wykonuj/reaguj dla portu 80 (domyślny http) oraz serwera o nazwie ‚pogoda.wiks.eu’ – może tu być ‚localhost’ gdy uruchamiamy na swojej lokalnej maszynie,

ServerAdmin webmaster@localhost
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined

informujemy Apache gdzie wysłać maila z problemami natury administracyjnej, oraz gdzie umieszczać logi serwera Apache dotyczące działań na tej stronie,

# /manage/static/admin /img/icon-addlink.svg

powyższa linijka jest komentarzem, jak wszystko co w tym pliku zaczyna się od #.

Tego powyższego linku używałem, aby sprawdzić w którym miejscu są dostępne pliki Statyczne Admina Django na serwerze, aby wpisać to w następną linijkę, tj:

Alias /manage/static/admin /usr/local/lib/python2.7/dist-packages/django/contrib/admin/static/admin
<Directory /usr/local/lib/python2.7/dist-packages/django/contrib/admin/static/admin>
Require all granted
</Directory>

…czyli jeśli w ścieżce adresu początek to ‚/manage/static/admin’ należy odwzorować resztę na pliki dostępne pod lokalnym katalogiem ‚/usr/local/lib/python2.7/dist-packages/django/contrib/admin/static/admin’

A sprawdziłem to używając wspomnianej wcześniej – zakomentowanej ścieżki, dla jednego z plików graficznych Django Admina.

Alias /manage/static /home/wiks/Dokumenty/projects/weather/LINUXserver/duser/duser/app/static
<Directory /home/wiks/Dokumenty/projects/weather/LINUXserver/duser/duser/app/static>
Require all granted
</Directory>

Dostęp do plików statycznych naszej apki – tam gdzie ona jest umieszczona.

<Directory /home/wiks/Dokumenty/projects/weather/LINUXserver/duser/duser>
<Files wsgi.py>
Require all granted
</Files>
</Directory>

Ścieżka do pliku wsgi.py Django (o nim za chwilę), oraz:

WSGIDaemonProcess proj_manage python-path=/usr/local/lib/python2.7/dist-packages
WSGIProcessGroup proj_manage
WSGIScriptAlias /manage /home/wiks/Dokumenty/projects/weather/LINUXserver/duser/duser/duser/wsgi.py

czyli ustawienie ścieżki Pythona i użytkownika/grupy mającej do niej dostęp, a także wykonywanie/użycie Pythonowego wsgi.py dla aliasu ścieżki ‚/manage’

Dzięki ustaleniu aliasu ‚/manage’ a także innych, możemy pod jednym serwerem Apache uruchomić tradycyjne strony HTML, PHP oraz wiele aplikacji Pythonowych. Bosko.

O naszym aliasie ‚/manage’ musimy pamiętać, przy ustawieniach w pliku Djangowym settings.py

U mnie znalazł się on w settings.py tutaj:

BASE_URL = '/manage'  # albo '/fikusny/url'  # albo '/bardzo/fikusny/url'
# wszystkie jednak muszą się zgadzać z tym co w pliku konfiguracyjnym Apache.

STATIC_URL = BASE_URL + ‚/static/’
# co przekłada się na ścieżki w templatkach, tam gdzie używamy obrazów i plików statycznych:

<link rel="stylesheet" type="text/css" href="{% static 'css/mystyle.css' %}">

a także tam, gdzie używamy w templatkach

<a href="{% url 'index' %}...

odnośników do ścieżek z urls.py .

chmod x+ /home/wiks/Dokumenty/projects/weather/LINUXserver/duser/duser/duser/wsgi.py

Oczywiście należy zadbać, aby Apache2 miał dostęp i odpowiednie uprawnienia do wszystkich zdefiniowanych dla niego ścieżek, plików statycznych folderów logu (logów Apache i logów Django jeśli są) oraz odpowiednie pliki mogły były wykonywalne. W przypadku posługiwania się bazą SQLite3 uprawnienia muszą być przyznane także dla folderu zawierającego plik bazy (SQLite tworzy sobie pliki tymczasowe, jeśli Apache nie będzie miał uprawnień do zapisu w folderze obejmującym bazę – wygeneruje wyjątek):

sudo chown :www-data ~/duser/db.sqlite3
sudo chown :www-data ~/duser

‚Zezwalamy’ na użycie konfiguracji – utworzy to link do wpisanego pliku w katalogu sites-enabled:

a2enconf wsgi_manage

i restart Apache2 (należy go wykonywać po każdej zmianie w plikach Django -prócz statycznych i templatek)

sudo service apache2 restart

Plik urls.py – bez zmian w stos do Debug: True (fragment z paska adresu ‚/manage’ zabiera sobie Apache2):

# duser/urls.py
from django.conf.urls import include, url
from django.contrib import admin

urlpatterns = [
url(r'^admin/', include(admin.site.urls)),
url('^', include('app.urls')),
]

uWSGI

Uruchamiając apkę Django na serwerze zdalnym Linuxpl.com (jaki ten świat mały, apka pisana w Świnoujściu, a Linuxcom.pl w Rzeszowie – blisko kochanych Bieszczadów) jako pogoda.wiks.eu/manage nie miałem oczywiście wpływu na serwer, musiałem ją uruchomić przez sugerowany uWSGI, co spowodowało jednak, że serwer ‚nie zabierał’ fragmentu ‚/manage’ z paska adresu (pod sub-domeną były też -głownie pliki PHP, HTML…) więc musiałem to zrobić w ‚urls.py’:

# duser/urls.py

url(r'^manage/static/admin/(?P<path>.*)$', 'django.views.static.serve', 
{'document_root': '/home/wiks/python/venv/proj_gpsmim/lib/python2.7/site-packages/django/contrib/admin/static/admin'}),

url(r'^manage/admin/', include(admin.site.urls)),
url(r'^manage/', include('app.urls')),

]

Dodatkowo, nie mogąc również poprzez wsgi serwera serwować plików statycznych, zrobiłem to w pliku urls.py powyżej, rzutując wszystko co jest za ‚manage/static/admin/’ w pasku adresu na folder przechowujący pliki statyczne Admina Django w moim virtualnym środowisku ~python/venv/proj_gpsmim (…tak, wcześniej poszukałem tego poprzez FTP -analogicznie jak w przypadku w WSGI na lokalnym własnym serwerze).

Pytanie co z plikami statycznymi apki?

Serwuje je poprzez urls.py wewnątrz app w taki sposób:

# coding=utf-8

from django.conf.urls import url, include
import views_cpl
from duser import settings

urlpatterns = [
url(r'^static/(?P<path>.*)$', 'django.views.static.serve', 
{'document_root': settings.STATIC_ROOT}),
[...]

Tutaj już mamy ‚zabrane’ ‚manage/’ ze ścieżki adresu (pierwszy plik urls.py tego dokonał), i oczywiście poprawnie trzeba ustawić STATIC_ROOT w settings.py:

BASE_DIR = os.path.dirname(os.path.dirname(os.path.abspath(__file__)))
STATIC_ROOT = BASE_DIR + "/app/static"

Oczywiście -jak wcześniej- warunkiem powodzenia jest ustawienie dostępu do plików oraz uprawnień do ich uruchamiania -tam gdzie to wymagane.

Komenda uruchamiająca apkę to w moim wypadku:

-uruchomienie w wirtualnym środowisku:

source /home/wiks/python/venv/proj_gpsmim/bin/activate

i uruchomienie:

nohup uwsgi --plugin http,python --http 127.0.0.1:8892 --chdir /home/wiks/python/django/pogoda/ --wsgi-file duser/wsgi.py --master --processes 1 --workers 1 --threads 1 --daemonize=/home/wiks/python/django/pogoda/logs/log.txt

czyli:

uruchom na porcie 8892,

katalog roboczy:

–chdir /home/wiks/python/django/pogoda/

plik wsgi.py (Djangowy):

–wsgi-file duser/wsgi.py

i miejsce na log servera:

–daemonize=/home/wiks/python/django/pogoda/logs/log.txt

Resztę magii wykonają poproszeni Panowie Administratorzy Linuxpl.com .

 

ładnie jest to opisane tutaj:

https://docs.djangoproject.com/

https://www.digitalocean.com/

https://uwsgi-docs.readthedocs.io

https://support.linuxpl.com