1 votes

Après avoir configuré nginx (reverse proxy) et gunicorn, les variables env cessent d'être détectées (application Django sur Ubuntu)

Sur une machine ubuntu hébergeant mon application Django (avec un backend postgres), mes variables env ont été parfaitement détectées lorsque j'ai lancé gunicorn comme seul serveur web en utilisant la commande gunicorn --bind 0.0.0.0:8080 --env DJANGO_SETTINGS_MODULE=myproject.settings myproject.wsgi:application

Ensuite, j'ai installé nginx et je l'ai configuré pour qu'il agisse comme un proxy inverse avec gunicorn (en utilisant un digital ocean guide ici ). Il n'y a pas de superviseur. Cette nouvelle configuration du serveur web a démarré correctement, sauf que maintenant il ne détecte pas du tout les variables env.

Imaginez que mes variables env sont éveillé=1 y secret=abc123 . J'ai déjà essayé de mettre export awake=1 y export secret=abc123 en /etc/default/nginx en gunicorn.conf en /etc/environment (qui les définit globalement). J'ai également essayé de les ajouter à nginx.conf en tant que env awake=1; y env secret=abc123; .

Rien n'a fonctionné.

Maintenant, il semble que nginx

supprime toutes les variables d'environnement héritées de son processus parent sauf la variable TZ

Source : http://nginx.org/en/docs/ngx_core_module.html#env Cela pourrait-il être la raison pour laquelle rien de ce que j'essaie ne fonctionne ? Néanmoins, echo $awake donne 1 sur la ligne de commande, ce qui m'indique que les variables sont peut-être définies, mais qu'elles sont contournées ou ignorées.

C'est devenu très frustrant. Quelqu'un peut-il m'aider à résoudre ce problème ? Merci d'avance.


wsgi.py :

import os
os.environ.setdefault("DJANGO_SETTINGS_MODULE", "myproject.settings")
from django.core.wsgi import get_wsgi_application
from dj_static import Cling
application = Cling(get_wsgi_application())

gunicorn.conf :

description "Gunicorn application server handling myproject"

start on runlevel [2345]
stop on runlevel [!2345]

respawn
setuid myuser
setgid www-data
chdir /home/myuser/directory/myproject/

exec /home/myuser/.virtualenvs/myvirtualenv/bin/gunicorn --chdir=/home/myuser/directory/ --workers 3 --bind unix:/home/myuser/directory/myproject/myproject.sock --env DJANGO_SETTINGS_MODULE=myproject.settings myproject.wsgi:application

/etc/nginx/sites-available/myproject :

server {
    listen 80;
    server_name myapp.cloudapp.net;

    location = /favicon.ico { access_log off; log_not_found off; }
    location /static/ {
        root /home/myuser/directory/myproject;
    }

    location / {
        include proxy_params;
        proxy_pass http://unix:/home/myuser/directory/myproject/myproject.sock;
    }
}

Note : Veuillez demander plus d'informations si vous en avez besoin.

0 votes

Où devez-vous utiliser ces variables d'environnement ?

0 votes

J'ai configuré postgres et Amazon S3 dans le fichier de configuration de mon projet. paramètres.py en fonction de ces variables d'environnement. Je les détecte dans settings.py via os.environ.get('awake') par exemple. Il m'a bien servi pendant un mois. Récemment, j'ai migré mon infrastructure et j'ai changé la configuration de mon serveur web pour inclure nginx comme proxy inverse. Maintenant, je me heurte à ce mur où les variables env qui étaient auparavant détectées (et semblent toujours être correctement définies si l'on fait printenv ) n'ont plus aucun effet sur settings.py. Le code de l'application n'a pas changé. Les définir dans /etc/environment n'avait aucun effet non plus !

0 votes

N'est-il pas possible de les définir littéralement dans le code ?

1voto

Sophia111 Points 26

Je suggère de définir vos variables env à l'endroit où vous exécutez gunicorn, comme ceci : gunicorn --bind0.0.0.0:8080 -e var1=value1 -e var2=value2 myproject.wsgi:application . Cela devrait fonctionner pour vous.

1 votes

Il doit y avoir un meilleur moyen, non ? Gunicorn ne peut pas voir les variables os.environ sans cela ?

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X