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 faitprintenv
) 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 ?
0 votes
Oui, si tout le reste échoue, je devrai faire ce choix. Idéalement, je ne veux pas mettre mes clés secrètes et autres dans le code. De même, mon application est vivante séparément sur Heroku et Azure à la fois. Quand elle est sur Azure, je veux qu'elle détecte qu'elle est sur Azure à partir de l'environnement (idem pour Heroku).
0 votes
Vous pourriez lire la clé secrète à partir d'un fichier texte. Mais vous avez raison, c'est une solution de contournement, pas une solution.