Nginx et Gunicorn 'err_conn_refused', mais nginx n'essaie pas d'save

J'ai joué avec Django Cookie Cutter pour des projets locaux et je voulais le mettre sur mon DO Droplet comme environnement de mise en scène semi-productif.

Le server est mis en place avec Nginx reverse proxying à une variété de projets, certains servis avec Gunicorn, l'un avec la flare nue et l'autre avec uWSGI. Chaque projet a sa propre virtualisation.

Lors du deployment du projet et de la configuration, j'ai la succession d'erreurs suivantes.

Nginx conf est comme suit (qui reflète les autres sites sur cette gouttelette):

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"'; } } 

En premier lieu, après avoir réinitialisé nginx et ne pas configurer Gunicorn, cela "fonctionne" / fait ce que je m'attends: lance une erreur 502 Bad Gateway et les journaux nginx note:

 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:$ 

Bien, alors, en commençant Gunicorn:

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

(exécuter à partir d'un dossier qui a manage.py in) – cela lance une 400 mauvaise request dans le browser; les notes du server Gunicorn (pendant que je suis ssh'd et je peux voir):

 [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. 

Cela prend du sens: django-cookiecutter place la plupart des configurations sensibles dans les variables d'environnement. Mon file .env (et j'ai vérifié qu'il est disponible en shell) ressemble à ceci:

 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 

Si j'exporte DJANGO_ALLOWED_HOSTS=127.0.0.1 (la variable env qui mappe à ALLOWED_HOSTS dans les Paramètres de Django) ou autre chose (string, pas de string, caractère générique, list), il semble rompre complètement quelque chose , et j'ai une erreur 'ERR_CONN_REF' dans le browser et l'URL du browser passent de test.myserver.com à 127.0.0.1:8085 (donc, évidemment, il ne se connecte pas, je ne gère pas un server sur mon localhost à ce port.)

Il n'y a rien dans le journal Nginx (je m'attends à une erreur en amont ici, en gros), et Gunicorn ne voit jamais la request. Il ne semble pas (bizarrement) apparaître dans le journal d'access nginx non plus.

J'ai également essayé de renommer l'env.example qui contient toutes mes variables à .env, mais cela ne semble pas faire beaucoup de différence.

J'ai évidemment manqué quelque chose, mais je ne suis pas sûr de quoi, et j'ai du mal à déboguer; les autres sites en cours d'exécution sont bien, et nginx n'est généralement pas affecté. En essayant de unset DJANGO_ALLOWED_HOSTS a supprimé de .env, mais j'ai toujours le problème, après avoir réinitialisé nginx.

Edit: Je suis returnné à la dernière configuration 'working' (c.-à-d. Jeter le 400 Bad Request et les choses en cours de connection) uniquement en supprimant et en reconstruisant le virtualenv; Je ne veux vraiment pas le faire plusieurs fois car il y a beaucoup de dependencies et ça prend du time!

Deuxième édition: lors de l'inspection des parameters d'environnement à l'aide de django-environ, il semble que cette command d'export a détruit le format:

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

Cela ne semble pas correct, ne devrait-il pas être séparé par des virgules? J'ai l'printing que c'était la bonne command à entrer avant, donc raisonnablement incertain comment procéder ici …

La réponse dans ce cas particulier concerne le manque de jointure entre le file de parameters de production.py et les parameters d'environnement, lorsque vous n'utilisez pas Heroku ou Docker. ( Tiré du numéro 490 )

Mes problèmes étaient deux: ici, un mauvais format pour les hôtes autorisés, causé par une concaténation incorrecte des strings, et nécessitant de mettre:

"Dans votre file de configuration (par exemple, common.py ), vous pouvez le lire de la manière suivante: env.read_env(ROOT_DIR('.env') ) selon l'endroit où vous mettez votre copy."

Cela a fait immédiatement que les variables d'environnement (anciennement définies) soient disponibles pour le shell et le programme. Je ne vais pas entrer dans les bugs introuvables que j'ai eu à la suite de faffing sans fin, c'est une autre histoire. 🙂

Modifier après un certain time: il y avait un problème connexe à ceci – dans le file nginx conf pour le site (dans les sites-available ), je devais append

proxy_set_header Host $http_host; pour s'assurer que le nom d'hôte correct a été passé; Cela empêche la redirection vers localhost qui se produit dans certaines circonstances.

Mon dossier complet du site est donc maintenant:

 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"'; } }