Czy Django może działać na samym Gunicorn (bez Apache lub nginx)?

Question

Próbowałem już prawie każdego tutoriala django + nginx w Internecie i nie mogę uzyskać pliku obrazu do wyświetlenia na ekranie. To zawsze stara historia - 404 PAGE NOT FOUND. Strona ładuje się dobrze, ale django.png w moim folderze /static/ nie. Nie wiem, czy jest to problem w ustawieniach settings.py lub w Nginx.

Jestem tak sfrustrowany, że odmawiam spojrzenia na inny "Jak uzyskać poradnik nginx/django". Czy jeśli zainstaluję stronę w najbliższym czasie, czy Gunicorn będzie wystarczał do uruchomienia witryny Django i jednoczesnego udostępniania plików statycznych bez korzystania z Apache lub nginx? Czy istnieje duża korzyść z posiadania odwrotnego proxy w pierwszej kolejności?

Answer 1

Tak. Gunicorn może również służyć twoim statycznym.

Jeśli wszystko inne zawiedzie, niech Django zrobi to za Ciebie Aby to zrobić, po prostu trzeba dodać kolejny wzorzec adresu URL w następujący sposób (choć to zrobić w ostateczności przed frustracją.):

urlpatterns = patterns('', 
    # ... the rest of your URLconf goes here ... 
) + static(settings.MEDIA_URL, document_root=settings.MEDIA_ROOT) 

Podczas gdy obsługa django jest statyczna jest lepsza niż wcale jej nie obsługuje, warto delegować ją na serwery zoptymalizowane pod kątem tego samego jak nginx.

Zalecam uruchomienie nginx na innym porcie, aby rozpocząć, i zmianę ustawienia STATICH_URL django tak, aby obejmował port (po potwierdzeniu, że port obsługuje statystykę). - Robienie tego jest tak proste, jak zrobienie prostego linku do MEDIA_ROOT z folderu nginx.

A jeśli używasz nginx, to dobrze jest również proxy wszystkich żądań za pomocą go i tylko przekazać żądanie django do gunicorn. Wszystko to wymaga dodania pliku conf, który mówi odpowiednio nginx.

Widzę, jak to może być mylące dla tych, którzy zaczynają i próbują zrobić wszystko (żądania proxy, służyć statycznie, skonfigurować nginx) na raz. Spróbuj to jeden po drugim. Zdobądź media od gunicorn; Następnie użyj go z nginx, a następnie w końcu uzyskaj również serwer proxy nginx. Ale zrób to wszystko, zanim będziesz mieć swoją aplikację w produkcji. Takie podejście, które widziałem, zwiększa zrozumienie i zmniejsza frustrację.

Answer 2

Jeśli korzystasz już z serwisów internetowych Amazon, możesz korzystać z zasobników s3 do przechowywania statycznej zawartości i wdrażania aplikacji do formatu ec2 za pomocą gunicorn (lub cokolwiek chcesz). W ten sposób nie musisz się martwić o ustawienie własnego statycznego serwera plików.

dokumentacja

Answer 3

Gunicorn zauważa, że ​​bez buforowania proxy powolnych klientów, domyślny pracownik jest podatny na atak Denial of Service: http://gunicorn.org/deploy.html

Chociaż istnieje wiele serwerów proxy HTTP dostępne Zalecamy że używasz Nginx. Jeśli wybierzesz inny serwer proxy, musisz upewnić się, że buforuje on wolnych klientów, gdy używasz domyślnych pracowników Gunicorn . Bez tego buforowania Gunicorn będzie łatwo podatny na ataki typu odmowa usługi. Możesz użyć slowloris, aby sprawdzić, czy twój serwer proxy zachowuje się poprawnie.

Może tak nie być w przypadku korzystania z asynchronicznych pracowników, takich jak gevent lub tornado.

Answer 4

Wykonałem za pomocą oprogramowania pośredniego Werkzeug.Czy to nie piękne, ani wydajnych jak przy użyciu serwera nginx, ale spełnia swoje zadanie:

zestaw STATIC_ROOT na settings.py

# project/settings.py 
import os 
BASE_DIR = os.path.dirname(os.path.dirname(__file__))) 
STATIC_ROOT = BASE_DIR+'/static-collected' 

Niż powiedzieć Werkzeug służyć pliki z tego folderu

# project/wsgi.py 
import os 
BASE_DIR = os.path.dirname(os.path.dirname(__file__)) 

(...) 
from django.core.wsgi import get_wsgi_application 
application = get_wsgi_application() 
(...) 

import os 
from werkzeug.wsgi import SharedDataMiddleware 
print 'Installing WSGI static files server middleware' 
application = SharedDataMiddleware(application, { 
    '/static': os.path.join(BASE_DIR, 'static-collected'), 
}) 

Gdy DEBUG = True, Django wyświetla pliki. Kiedy DEBUG = False, Werkzeug wyświetla pliki z foldera zebranego statycznie. Musisz uruchomić funkcję collectstatic na serwerze, który używa DEBUG = False, aby to działało.

Obs: Z jakiegoś powodu Werkzeug daje 500 nie odnalezionych plików, a nie 404. Jego dziwne, ale wciąż działa. Jeśli wiesz dlaczego, prosimy o komentarz.

Answer 5

Polecam przy użyciu Nginx z przodu z kilku powodów:

• konserwacji lub wewnętrzna strona błędu serwera można łatwo wdrożyć, gdy gunicorn jest w dół. Oznacza to, że zawsze będziesz miał coś do powiedzenia, jeśli twój serwer aplikacji nie działa.
• Jak sugeruje Gunicorn doc, ataki http takie jak DOS nie są wykrywane.
• Możesz później zaimplementować swoją własną strategię równoważenia obciążenia. Stanie się to ważniejsze dla inżynierii oprogramowania, ponieważ twój projekt skaluje się. Osobiście uważam AWS ELB za mało wiarygodny i myślę o tym.

Aktualizacja:

Także, proszę zobaczyć również pisemną odpowiedź od dewelopera Gunicorn:

Why do I need Nginx and something like Gunicorn?