I am having some trouble setting environment variables in my production environment, I have some logic in django settings that depends on it. I have tried exportng it through variouse places '/etc/profile, ~.bashrc, etc'
The problem is that those only set them when there is a login (I believe?) But if I navigate a browser to the server I can see that the variable was not set correctly through the debug. I am running django1.7/gunicorn/nginx. I suspected to put it in the gunicorn /etc/init/gunicorn.conf but that did not work.
How can I set this?
You could set them in the WSGI file. – Simeon Visser
Thanks, this solved my problem for my purposes. I don't believe that the wsgi file runs on the dev server so it worked perfectly and only set the variable on the production. Thanks
Related
I think this is a simple fix, but I've deployed quite a few Django apps to Heroku and I still can't figure out what's going on.
Accessing https://dundjeon-finder.herokuapp.com/ gives me a 500 error when using the browser/curl, but if I shell into the app using heroku run ./manage.py shell I can render the views no problem. My logs aren't telling me anything (just that the response is 500) despite DEBUG being set to True, and Sentry isn't receiving an error (it has previously when the database env variable was set badly), so I'm assuming it's something to do with the way the request works.
The repo is public, any help would be much appreciated! The settings file is here.
Well it was because of using asgi instead of wsgi. I'm not sure why that caused the errors, but will do some more searching.
I updated one environment variable inside settings.py and restarted gunicorn, but it is seeing the old settings. Here is the command I use to start it:
nohup /opt/my_proj/.virtualenvs/my_proj/bin/python2 /opt/my_proj/.virtualenvs/my_proj/bin/gunicorn --bind=0.0.0.0:8008 --timeout=1800 --log-level=debug --error-logfile=/opt/my_proj/gunicorn_nik.log --enable-stdio-inheritance --capture-output --user=me --pythonpath=/opt/me/code/my_proj,/opt/me/code/my_proj/seqr_settings wsgi &
I printed out paths to make sure that the scripts are running under my 'my_proj' directory and also looked up in 'gunicorn_nik.log' verifying that there I see it pointing to 'my_proj' folder. Then I removed settings.py to make sure still that it is the file gunicorn is picking up. The startup failed. I tried modifying settings.py printing out something from it but it is not working, logger.info is not printing from there.
I have several Django projects on one cluster node running (not sure that it is important).
Its as if Django is storing some cached file and using it, but how come gunicorn restart does not fix it? Seems weird to me. Any suggestions would be greatly appreciated.
The issue was that in .bashrc an environment variable was set that was somehow overwriting the value in settings.py that was having the same name.
I know my .env file is loading but for some reason it seems to be jumping back to 'config.settings.local'?
I am using the latest Cookiecutter code.
this is my .env settings.
DJANGO_ALLOWED_HOSTS=178.128.108.20,178.128.108.20:8000,*
DJANGO_ADMIN_URL=admin
DJANGO_DEBUG=True
DJANGO_SETTINGS_MODULE='config.settings.production'
DJANGO_SECRET_KEY=2l#$#-#2z...=6n7-ejd%+51
below are the settings I get back from Ubuntu after it can not find the allowed host setting.
The DJANGO_ALLOWED_HOSTS is set for the correct address but I get back an error about not being set.
Than I noticed some setting like the DJANGO_SETTINGS_MODULE have changed back to the local host.
Any ideas why?
Here is what I get back from my development server. Note the change in the config.setting to local.
And here is my disallowed host message back from Ubuntu.
As you can see the local host is set for this address.
here is the beginning Cookiecutter code:
env = environ.Env()
READ_DOT_ENV_FILE = env.bool('DJANGO_READ_DOT_ENV_FILE', default=True)
if READ_DOT_ENV_FILE:
# OS environment variables take precedence over variables from .env
env.read_env(str(ROOT_DIR.path('.env')))
All this admin stuff is not my thing. Sorry if it is foolish question.
Thanks.
I spent days chasing this issue and it turns out that if you do not set up Cookiecutter for either Heroku or Docker it does not set up the .envs folders that are needed.
Once I rebuilt the site with the Heroku option, I was able to solve my .envs issues.
use_heroku [n]: y
I can now set it up on Ubuntu (using Digital Ocean) and get the 'config.settings.production' to work.
Cheers.
After having an unexpected shutdown on my DEV machine, when going back to Pycharm project, I noticed the Django view file I was editing (which had 700+ lines) when that happened, it was completely empty. I managed to restore it from a backup; no loss there.
The problem comes up when trying to debug, it returns this error: "ImproperlyConfigured: Requested setting DEFAULT_INDEX_TABLESPACE, but settings are not configured. You must either define the environment variable DJANGO_SETTINGS_MODULE or call settings.configure() before accessing settings." Process finished with exit code 137
The Pycharm settings Django Support (project root, settings & manage script) have the expected values as well.
If I run the project with the ./manage .py runserver command, everything is fine. I can even access the DB with manage.py dbshell. I looked at my settings file and everything seems OK. I also updated from version 3.0.1 to 3.1.1, and no difference.
I'm using Django 1.6.1 and postgresql 9.2.7. What can I do?
For Pycharm, just go to Run -> Edit Configurations, select your project on the right of the window from Debug Configuration, and you will see Environment variables on the right. Make sure you have set DJANGO_SETTINGS_MODULE=mysite.settings, if not just add one, it is as easy as fill a key value pair from the pop up dialog.
I'm using PyCharm Professional and the answers provided here didn't work for me.
I went to Build, Execution, Deployment -> Consule -> Django Console and then added DJANGO_SETTINGS_MODULE=my_app_name.settings to Environment Variables.
I currently have a running production Django application on Heroku. Unfortunately, I haven't been able to turn off the DEBUG setting on Heroku. Turning it off locally works fine, but when pushed to Heroku (after heroku config:set DEBUG=False), it doesn't apply.
The error pages are still the default DEBUG ones instead of the 404, 403, and 500 templates in our template root.
I have also tried using a DJANGO_DEBUG setting in case there were any environment conflicts with DEBUG, and casting the result to a boolean in the settings file. heroku config shows the settings in the environment are correct. This is on Django 1.3, Heroku Cedar.
Any tips or solutions?
Does your django settings.py file even look in the environment?
It does not, by default, care about anything you've set in the environment (via "config:set"). If you're "casting" the environment to a boolean, make sure you're casting it correctly. bool('False') is still True.
It's simplest just to detect if the environment variable exists so you don't have to worry about type casting or specific formats of the configuration.
DEBUG = os.environ.get('DEBUG', False)
To disable debug, remove the variable from the environment instead of trying to type cast... it just seems much more reliable and fool proof. config:unset DEBUG
The problem is that the environment variable is not a boolean, rather a string.
So do place below line in settings.py
DEBUG = (os.environ.get('DEBUG_VALUE') == 'True')