настройка gunicorn + nginx

Question

есть такой момент, я настроил gunicorn + nginx + django на своём сервере, подрубил домен. При переходе по домену я получаю 404 ошибку и пути куда можно перейти, /admin, /api и тд.

Мне нужно что бы при переходе на домен меня сразу кидало в админку.

До этого я настраивал так что бы запускать gunicorn вручную через --daemon.
И в этом случае я мог прописать так:

location / {
     proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
     proxy_set_header Host $http_host;
     proxy_redirect off;
     proxy_pass http://127.0.0.1:8000/admin/;
    }
location /admin/ {
     proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
     proxy_set_header Host $http_host;
     proxy_redirect off;
     proxy_pass http://127.0.0.1:8000/admin/;
    }
location /api/ {
     proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
     proxy_set_header Host $http_host;
     proxy_redirect off;
     proxy_pass http://127.0.0.1:8000/api/;
    }

Но сейчас настройка такая:

server {
    listen 80;
    server_name server_domain_or_IP;

    location = /favicon.ico { access_log off; log_not_found off; }
    location /static/ {
        root /home/user/backend;
    }
    location /media/ {
        root /home/user/backend;
    }

    location / {
        include proxy_params;
        proxy_pass http://unix:/run/gunicorn.sock;
    }
}

И я не могу прописать так же.

Answer 1

Решил эту проблему так:

upstream django {
    server unix:/run/gunicorn.sock;
    server 127.0.0.1:8000
}
server {
    listen 80;
    server_name sub.domain.ru www.sub.domain.ru;
    location /favicon.ico {access_log off; log_not_found off; }
    location /static/ {
        root path_to_project; #  example = root /home/backend;
    }
    location /media/ {
        root path_to_project; #  example = root /home/backend;
    }
    location / {
        include proxy_params;
        uwsgi_pass django;
        proxy_pass http://django/admin/; 
    }
    location /admin/ {
        include proxy_params;
        uwsgi_pass django;
        proxy_pass http://django/admin/; 
    }
    location /api/ {
        include proxy_params;
        uwsgi_pass django;
        proxy_pass http://django/api/; 
    }
}

Answer 2

Я прокомментирую окончательную конфигурацию nginx в виде ответа, потому что для комментария мой текст будет слишком длинным.

Я попал на эту страницу в поисках ответа на вопрос, может ли вообще WSGI-сервер Gunicorn работать с обратным прокси-сервером не по протоколу HTTP, а по бинарному протоколу uwsgi, и в качестве ключевых слов для поискового запроса я использовал "gunicorn uwsgi_pass".

И когда я посмотрел на конфигурацию nginx, приведенную в ответе, я очень сильно удивился, потому что вначале вообще не понял, как она может проходить валидацию при старте nginx.

Немного поясню. Каждый блок location в обязательном порядке имеет так называемый обработчик содержимого (content handler), отрабатывающий на фазе обработки запроса NGX_HTTP_CONTENT_PHASE (см. описание фаз обработки запроса в руководстве разработчика nginx).

Модуль-обработчик содержимого может быть указан в явном виде с помощью одной из директив ..._pass (proxy_pass, fastcgi_pass, uwsgi_pass и т.д.). Если обработчик не будет указан в явном виде, то по умолчанию в качестве обработчика содержимого будет использован модуль static, чья задача, как несложно догадаться - отдача статического контента.

Так вот, и директива proxy_pass, и директива uwsgi_pass задают соответствующие обработчики содержимого, и по идее одновременно работать не могут. И не работают, как я только что проверил. В качестве обработчика содержимого будет использован последний по очерёдности обработчик, указанный в соответствующем блоке location (в данном случае это будет модуль ngx_http_proxy_module). Если бы очерёдность директив uwsgi_pass и proxy_pass была другой, конфигурация просто была бы неработоспособной. И, да, я думаю, что ответ на свой исходный вопрос я таки нашёл. Учитывая то, что данный issue до сих пор не закрыт, скорее всего Gunicorn действительно (пока что?) не умеет работать по протоколу uwsgi.

P.S. И ещё, суффиксы /admin/ и /api/ в последних двух директивах proxy_pass являются избыточными. Они не влияют на работоспособность конфигурации, но несколько лишних процессорных тактов при обработке каждого запроса скорее всего украдут. Подробнее в документации:

Если директива proxy_pass указана с URI, то при передаче запроса серверу часть нормализованного URI запроса, соответствующая location, заменяется на URI, указанный в директиве.

БЛОГ НА HUSL

настройка gunicorn + nginx

Ответы (2 шт):