Nginx e Gunicorn 'err_conn_refused', mas nginx não está registrando erro

Question

Eu tenho brincado com o Django Cookie Cutter para projetos locais e queria colocá-lo no meu DO Droplet como um ambiente de preparação de semi-produção.

O servidor é configurado com o proxy reverso Nginx para uma variedade de projetos, alguns servidos com o Gunicorn, um com o Flask nulo e um com o uWSGI. Cada projeto tem seu próprio virtualenv.

Ao implantar o projeto e configurá-lo, tenho a seguinte sucessão de erros.

O Nginx conf é o seguinte (que espelha os outros sites nesta gota):

server {
        server_name test.myserver.com;

        access_log off;

        location /static/ {
            alias /var/www/myproject/static/;
        }

        location / {
                proxy_pass http://127.0.0.1:8085;
                proxy_set_header X-Forwarded-Host $server_name;
                proxy_set_header X-Real-IP $remote_addr;
                add_header P3P 'CP="ALL DSP COR PSAa PSDa OUR NOR ONL UNI COM NAV"';
        }
    }

Na primeira instância, depois de resetar o nginx e não configurar o Gunicorn, isso 'funciona' / faz o que eu esperava: gera um erro 502 Bad Gateway e o registro nginx nota:

2016/02/25 11:27:25 [error] 21217#0: *275 connect() failed (111: Connection refused) while connecting to upstream, client: my.ip.address, server: test.myserver.com, request: "GET / HTTP/1.1", upstream:$

Tudo bem, começando pelo Gunicorn:

/var/www/test.myserver.com/env/bin/gunicorn -b 127.0.0.1:8085 myproject.wsgi:application &

(executado a partir da pasta que possui o manage.py) - isso gera um 400 Bad Request no navegador; as notas do servidor gunicorn (enquanto eu estou ssh'd e posso ver):

[Django] ERROR: Invalid HTTP_HOST header: u'127.0.0.1:8085'.You may need to add u'127.0.0.1' to ALLOWED_HOSTS.

Faz sentido: o django-cookiecutter coloca a maior parte da configuração sensível em variáveis de ambiente. Meu arquivo .env (e eu verifiquei se ele está disponível no shell) se parece com isto:

TERM=xterm-256color
SHELL=/bin/bash
SSH_CLIENT=my.ip.address 57044 22
OLDPWD=/var/www/myproject/env
SSH_TTY=/dev/pts/0
USER=root
VIRTUAL_ENV=/var/www/myproject/env
MAIL=/var/mail/root


PATH=/var/www/treatout/env/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
        PWD=/var/www/treatout/env/bin
        LANG=en_US.UTF-8
        PS1=(env)${debian_chroot:+($debian_chroot)}\u@\h:\w\$ 
        SHLVL=1
        HOME=/root
        LOGNAME=root
        SSH_CONNECTION=82.23.204.106 57044 178.62.47.176 22
        _=/usr/bin/env

Se eu exportar DJANGO_ALLOWED_HOSTS=127.0.0.1 (a variável env que mapeia para ALLOWED_HOSTS nas Configurações do Django) ou qualquer outra coisa (string, não string, curinga, lista), parece quebrar completamente algo , e Eu recebo um erro 'ERR_CONN_REF' no navegador e a URL do navegador alterna de test.myserver.com para 127.0.0.1:8085 (então, obviamente, ele não se conecta, não estou executando um servidor no meu localhost nessa porta .)

Não há nada no Nginx Log (eu esperaria um erro de upstream aqui, basicamente), e Gunicorn nunca vê o pedido. Ele não aparece (estranhamente) no log de acesso do nginx.

Eu também tentei renomear o env.example que contém todas as minhas variáveis para .env, mas não parece fazer muita diferença.

Eu obviamente perdi alguma coisa, mas não sei o que, e estou tentando depurar; os outros sites em execução são bons, e o nginx geralmente não é afetado. Tentando unset DJANGO_ALLOWED_HOSTS removê-lo de .env, mas ainda tenho o problema, depois de redefinir o nginx.

Edit: Voltei para a última configuração 'working' (isto é, jogando o 400 Bad Request e coisas sendo registradas) apenas excluindo e reconstruindo o virtualenv; Eu realmente não quero fazer isso várias vezes, pois há muitas dependências e demora um pouco!

Segunda edição: Ao inspecionar as configurações do ambiente usando o django-environ , ele parece como esse comando de exportação atrapalhou o formato:

env('DJANGO_ALLOWED_HOSTS')
'my.server.ip.address:127.0.0.1'

Isso não parece certo, não deveria ser separado por vírgula? Eu sinto que foi o comando certo para entrar antes, então razoavelmente inseguro sobre como proceder aqui ...

    

Answer 1

A resposta neste caso específico está relacionada à falta de junção entre o arquivo de configurações production.py e as configurações do ambiente, quando você não usa Heroku ou Docker. ( Extraído da edição 490 )

Meus problemas eram dois aqui: formato incorreto para os hosts permitidos, causado pela concatenação inadequada das strings e pela necessidade de colocar:

"Em seu arquivo de configurações (por exemplo, common.py ), você pode lê-lo assim: env.read_env(ROOT_DIR('.env') ) dependendo de onde você colocou sua cópia."

Isso imediatamente tornou as variáveis de ambiente (previamente definidas) disponíveis para o shell e o programa. Eu não vou entrar nos insetos que eu tive como resultado de intermináveis abusos, são outra história. :)

Editar depois de um tempo: Houve um problema relacionado a isso - no arquivo conf nginx do site (em sites-available ) eu tive que adicionar

proxy_set_header Host $http_host; para garantir que o nome do host correto foi passado; isso impede o redirecionamento para localhost que acontece em determinadas circunstâncias.

Todo o meu arquivo de site é, portanto, agora:

server {
        server_name myservernamehere.com;

        access_log off;

        location /static/ {

            alias /var/www/mysitename/mysitename/mysitename/static/;
        }

        location / {
                proxy_pass http://127.0.0.1:8085;
                client_max_body_size 20M;
                proxy_set_header Host $http_host;
                proxy_set_header X-Forwarded-Host $server_name;
                proxy_set_header X-Real-IP $remote_addr;
                add_header P3P 'CP="ALL DSP COR PSAa PSDa OUR NOR ONL UNI COM NAV"';
        }
    }