Wiele wdrożeń aplikacji Django na serwerze EC2 Amazon korzysta z serwerów HTTP NGINX i Gunicorn.Jaki jest cel równoległego działania NGINX i Gunicorn?
Zastanawiam się, co tak naprawdę robią i dlaczego oba są używane równolegle. Jaki jest cel równoległego ich prowadzenia?
Nie są używane równolegle. NGINX to reverse proxy. Jest pierwszy w kolejce. Akceptuje połączenia przychodzące i decyduje, gdzie powinny iść dalej. Zwykle obsługuje również media statyczne, takie jak CSS, JS i obrazy. Może również wykonywać inne czynności, takie jak szyfrowanie przez SSL, buforowanie itp.
Gunicorn to kolejna warstwa i jest to application server. NGINX widzi, że połączenie przychodzące jest dla www.domain.com i wie (poprzez pliki konfiguracyjne), że powinien przekazać to połączenie do Gunicorn. Gunicorn jest serwerem WSGI który jest w zasadzie:
prosty i uniwersalny interfejs pomiędzy serwerami WWW i aplikacji internetowych lub ramami
praca Gunicorn jest zarządzanie i uruchamianie instancji Django (y) (podobne do używanie podczas programowania django-admin runserver)
Kontrastem do tej konfiguracji jest użycie Apache z modułem mod_wsgi. W tej sytuacji serwer aplikacji jest w rzeczywistości częścią Apache, działającym jako moduł.
@Timmy O'Mahony, Jaka jest różnica między plikiem wsgi (nadchodzi podczas tworzenia projektu django) a gunicorn – Shiva
[Ta odpowiedź] (http://serverfault.com/questions/220046/why -is-setting-nginx-as-a-reverse-proxy-a-good-idea) idzie głębiej w szczegóły i zalety nginx. –
Zobacz [to pytanie] (http://stackoverflow.com/questions/13004484/deploying-django-with-gunicorn-and-nginx/13004973#13004973), które zawiera nieco więcej szczegółów niż odpowiedź Timmy'ego. –
@BurhanKhalid dziękuję, pomogłeś – noahandthewhale