Wdrażanie Django z gunicorn i nginx

Nie jestem guru wdrażania, ale podzielę się niektórymi z moich Praktyk Wdrażania Django z gevent (powinno być podobne do gunicorn).

virtualenv jest świetny z powodów, do których nie pójdę. Jednak znalazłem virtualenv-wrapper (docs) bardzo przydatne, zwłaszcza gdy pracujesz nad wieloma projektami, ponieważ pozwala na łatwe przełączanie się między różnymi wirtualnymi plikami. Nie dotyczy to tak naprawdę środowiska wdrażania, jednak gdy muszę rozwiązywać problemy na serwerze za pomocą SSH, uznałem to za bardzo przydatne. Kolejną zaletą korzystania z niego jest to, że zarządza katalogiem virtualenv, więc mniej pracy ręcznej dla Ciebie. Virtualenvs mają być jednorazowe, więc w przypadku problemów z wersją lub innymi problemami z instalacją, możesz po prostu zrzucić env i utworzyć nowy. W rezultacie najlepszą praktyką jest nie dołączanie żadnego kodu projektu do virtualenv. Powinien być oddzielony.

Jeśli chodzi o konfigurację wielu witryn, virtualenv jest w zasadzie odpowiedzią. Ty powinien mieć oddzielny virutalenv dla każdego projektu. To samo może rozwiązać wiele problemów. Następnie podczas wdrażania inny proces Pythona uruchomi różne witryny, co pozwoli uniknąć ewentualnych konfliktów między wdrożeniami. Jednym z narzędzi, które szczególnie przydały mi się w zarządzaniu wieloma witrynami na tym samym serwerze jest supervisor (docs ). Zapewnia łatwy interfejs do uruchamiania, zatrzymywania i restartowania różnych instancji Django. Jest również w stanie automatycznie zrestartować proces, gdy awarii lub po uruchomieniu komputera. Więc na przykład, jeśli jakiś wyjątek zostanie podniesiony i nic go nie złapie, cała strona internetowa może zejść. Supervisor to złapie i automatycznie uruchomi instancję Django. Poniżej znajduje się przykładowy program nadzorujący (pojedynczy proces) config:

[program:foo]
command=/path/toviertualenv/bin/python deploy.py
directory=/path/where/deploy.py/is/located/
autostart=true
autorestart=true
redirect_stderr=True
user=www

Jeśli chodzi o dyrektywy root i alias, są one prawie takie same, z wyjątkiem przypadków, w których ich korzeń jest obliczany. In alias, whatever in the location in dropped, whether in root in it not. Obraz, który masz następujący nginx config:

location /static {
    alias /some/path/;
}
location /static2 {
    root /some/other/path/;
}

/static/hello/world.pdf => /some/path/hello/world.pdf
/static2/hello/world.pdf => /some/other/path/static2/hello/world.pdf

server {
    server_name .foodomain.com;
    listen 80;

    access_log logs/foodomain.log;

    gzip                on;
    gzip_http_version   1.0;
    gzip_comp_level     2;
    gzip_proxied        any;
    gzip_min_length     1100;
    gzip_buffers        16 8k;
    gzip_types          text/plain text/html text/css application/x-javascript text/xml application/xml application/xml+rss text/javascript;

    # Some version of IE 6 don't handle compression well on some mime-types, so just disable for them
    gzip_disable "MSIE [1-6].(?!.*SV1)";

    # Set a vary header so downstream proxies don't send cached gzipped content to IE6
    gzip_vary on;

    location / {
        proxy_read_timeout      30s;
        proxy_pass              http://localhost:8000;
        proxy_set_header        Host                 $host;
        proxy_set_header        User-Agent           $http_user_agent;
        proxy_set_header        X-Real-IP            $remote_addr;
    }

    location /media {
        alias   /path/to/media/;
        expires 1y;
    }

    location /static {
        autoindex on;
        expires   1y;
        alias     /path/to/static/;
    }

     location /favicon.ico {
        alias /path/to/favicon.ico;
    }
}

Mam nadzieję, że to ci trochę pomoże.

Cóż, jeśli chodzi o najlepsze praktyki, które zadałeś w swoim pytaniu, nie mogę pomóc w udostępnieniu narzędzia, które działało cuda dla mnie, dosłownie! Sam kiedyś się pomyliłem w kilku plikach konfiguracyjnych gunicorn, nginx, supervisorD dla kilku stron! Ale chciałem w jakiś sposób zautomatyzować cały proces, aby móc wprowadzić zmiany w mojej aplikacji/witrynie i wdrożyć go natychmiast. Jego nazwa to django-fagungis. Możesz znaleźć szczegóły mojego doświadczenia z Django Deployment automation tutaj . Właśnie skonfigurowałem fabfile.py ONCE (django-fagungis używa fabric do automatyzacji całego procesu i tworzy virtualenv na Twoim zdalnym serwerze, który jest bardzo przydatny do zarządzania zależnościami kilku witryn hostowanych na jednym serwerze. Używa nginx, gunicorn i supervisorD do obsługi projektu Django/site deployment) i django-fagungis klonuje mój najnowszy projekt z bitbucket (którego używam do wywrotowania) i wdraża go na moim zdalnym serwerze i muszę tylko wpisać trzy polecenia na powłoce mojej lokalnej Maszyny i że to!! Dla mnie okazało się to najlepszą i bezproblemową praktyką dla wdrożenia Django.

Sprawdź to dla minimalnej konfiguracji gunicorn i nginx wymaganej dla projektu Django. http://agiliq.com/blog/2013/08/minimal-nginx-and-gunicorn-configuration-for-djang/