I'm having trouble understanding the switchover from local to production settings for deploying Django projects. I'm using an Ubuntu virtual machine (VM) if it matters.
I understand how to configure my settings. I understand best practices for creating settings files (base.py, local.py, production.py, blah, blah). I know that in local development DEBUG=True, in production DEBUG=False, blah, blah.
But how do I implement this switchover in deployment? Do I get rid of the local.py? Do I create some kind of logic so that my VM only reads base.py and production.py?
What's the best approach?
I'm not sure about the best approach but what I do works...
At the foot of my settings.py, I have:
try:
from local_settings import *
except ImportError, e:
pass
I keep all my local development settings in local_settings.py which overide any production settings. I also make sure not to upload my local_settings.py file!
What you could do is to check in your settings py which environment is used at the moment.
To do this you can set an environment variable on your system that would have diffrent values on your development environment and the production environment.
you can set these environment variables by
sudo -H gedit /etc/environment
and add the following line in the file:
DEBUG="true"
(to make this changes available you will have to log out and log back in into your system)
in the production environment you would then set DEBUG="false".
then you can do this in your settings.py:
DEBUG = os.environ.get('DEBUG', 'true') != 'false'
and then you can set every setting that would be different depending on the environment that is used like this:
if DEBUG:
STATICFILES_STORAGE = 'whitenoise.storage.CompressedManifestStaticFilesStorage'
else:
STATICFILES_STORAGE = STATICFILES_STORAGE = 'custom_storages.StaticStorage'
(the setting above uses the local django server to serve staticfiles if it is in the development environment, and amazon s3 with boto if in the production environment (which is defined in the custom_storages module)
This way you can push your updates and always the right settings should be picked up depending on the environment.
Related
What is the expected process when one wants to deploy a django website automatically by means of a continuous integration process: how can we set debug mode to false without editing the configuration file?
Generally there are three very common approaches to switch between production and development environments in Django applications:
Create a separate settings.py file with a different name and point to it using the DJANGO_SETTINGS_MODULE environment variable. Once setting a value to it, the expected settings file within the project folder will be ignored.
Use Python conditional statements to check for variables specific to your environment like if settings.DEBUG: and decide for other ones within that block of code.
Make a settings directory inside the project folder and create three additional files; one for common settings variables like common.py, and another two for local and production specific variables such as dev.py and prod.py. You can specify your __init__ to always import common.py and try to import one of the others if they are found.
Generally, you don't change anything in your code repository when deploying to production. It's the same code as on your local machine. The only difference is that your app server (gunicorn or uwsgi) is running with a different DJANGO_SETTINGS_MODULE environment variable.
everyone!
Django 1.11 + PostgreSQL 9.6 + Gunicorn + Ubuntu 16.04 in AWS
I want to set environment variables for sensitive info.(django secret key, DB password...)
I studied many articles about setting ways.
But when I tried os.environ['env_name'],
.bashrc: Not working
.bash_profile: Not working
.profile: Not working
/etc/environment: Not working
Gunicorn script file.(systemd): I set them in gunicorn systemd script. It work very well.
But because I want to use the environment variables in other program too, I set them among 1~5 configurations. I don't understand why 1~5 configurations didn't work. Is there scope or priority of setting environment variables?
EDIT:
I use Ubuntu 16.04 server. I can't restart terminal session.
I tried 'source .bashrc' and logout/login. But It didn't work.
Of cource, 'echo $some_env_var' is working, I say, django can't read.
.bashrc will work for local development but not for a production environment. I just spent quite a bit of time looking for the answer to this and here's what worked for me:
1) Create a file somewhere on your server titled settings.ini. I did this in /etc/project/settings.ini
2) Add your config data to that file using the following format where the key could be an environmental variable and the value is a string. Note that you don't need to surround the value in quotes.
[section]
secret_key_a=somestringa
secret_key_b=somestringb
3) Access these variables using python's configparser library. The code below could be in your django project's settings file.
from configparser import RawConfigParser
config = RawConfigParser()
config.read('/etc/project/settings.ini')
DJANGO_SECRET = config.get('section', 'secret_key_a')
Source: https://code.djangoproject.com/wiki/SplitSettings (ini-style section)
The simplest solution is as already mentioned using os.environ.get and then set your server environment variables in some way (config stores, bash files, etc.)
Another slightly more sophisticated way is to use python-decouple and .env files. Here's a quick how-to:
1) Install python-decouple (preferably in a venv if not using Docker):
pip install python-decouple
2) Create a .env file in the root of your Django-project, add a key like;
SECRET_KEY=SomeSecretKeyHere
3) In your settings.py, or any other file where you want to use the configuration values:
from decouple import config
...
SECRET_KEY = config('SECRET_KEY')
4) As you probably don't want these secrets to end up in your version control system, add the file to your .gitignore. To make it easier to setup a new project, you could have a .env_default checked into the VCS containing default/dummy-values that's not used in production.
create a file called .bashrc in your server
export('the_name_in_bashrc', some_value)
then in the settings.py
import os
some_variable = os.environ.get('the_name_in_bashrc')
If you're using a virtual ENV you can add the environment variables to that specific environment. You can use export KEY=VALUE in your terminal but that will not persist. If you would like your values to persist you can edit the file:
sudo nano your_environment/bin/activate
Then at the bottom add the values you want e.g.:
export MY_KEY="12345"
And save. Remember to restart your ENV for changes to take effect.
pip install python-dotenv
Go To settings.py
import os
from dotenv import load_dotenv
load_dotenv('.env')
SECRET_KEY = os.getenv('SECRET_KEY')
Go To .env file
SECRET_KEY = your_secret_key
Trying to use 2 different settings file for production and dev.
I set DJANGO_SETTINGS_MODULE='mysite.settings_production'
Works perfectly when running server with runserver
When I run it with apache though, apache doesn't seem to use the setting in the ~/.bash_profile and instead use os.environ.setdefault("DJANGO_SETTINGS_MODULE", "mysite.settings") in the wsgi.py file
I guess it's maybe because apache is running on different user , not mine..
ok.. so it seems it's running as www-data on my ec2 ubuntu.
So I have to create the /home/www-data/.bash_profile and set the env variable?
It seems like so much hassle to use a different settings file.
Is there an obviously easier way to do this?
(I don't want to change the wsgi.py file, because it's source controlled)
Using bash_profile is completely the wrong way to do this.
The correct way is to use the wsgi.py file. However, since you don't want to do this (although I don't understand what it being version-controlled has to do with anything) then you can set environment variables directly in your Apache configuration using SetEnv:
SetEnv DJANGO_SETTINGS_MODULE mysite.settings
Well, it's really wrong way. Common method to have separate settings for different environment is to store environment-dependent in local_settings.py (or whatever you name it) and imprort from settings.py
from local_settings.py import *
don't put local_settings.py under project repository as you will override it with each commit. If you want to keep a sample of local settings, put into a separate file, e.g. local_settings.py.example
You can import local settings at the beginning of settings.py (so settings.py settings would override local settings), or at the end, or have two local settings files for both cases.
Here in comments to the answer, somebody asked this questions. But answer is still unclear for me .
I run my django site in Herouku and it requires dj-database-url module to work with Postgresql. How to run django with DATABASES = dj-database-url() in settings.py on my local computer? Changing code before pushing to Heroku is a pretty ugly way.
There are many ways to handle different production / development environments.
One is to have a local settings file that's imported at the bottom of your settings file that's not in version control, and thus not in heroku.
Another is any way to distinguish heroku environment from your local environment. An arbitrary environment variable, for example.
Another, is the default argument passed to dj_database_url which basically does this simple if statement for you.
import dj_database_url
DATABASES['default'] = dj_database_url.config(
default='sqlite:////path-to-my/database.sqlite')
Remember, this settings file is just python. You could have it use one database on Tuesday for example.. any if statement you can come up with will work.
I have a Django app on Heroku, with staging and production environments. Static files are hosted on S3. I'm streamlining my deployment process and plan to set up fabfiles once I have things working manually.
How can I configure collectstatic to push to multiple places? If I run it locally, it uses my dev settings (with a local STATIC_ROOT). If I run it on one of my Heroku apps (heroku run ./manage.py collectstatic), then it can't grab the files (since .slugignore ensures they're never pushed to Heroku). The same applies if I include collectstatic in my Procfile.
I'm also using django-pipeline, though it's not yet doing much since I'm stuck on the collectstatic bit.
UPDATE
In response to Marat's question, I tried passing a settings file as an option to collectstatic: ./manage.py collectstatic --settings=project.settings.prod, but got an error: Unknown command: 'collectstatic' I checked on the server though and Installed Apps does include django.contrib.staticfiles and I can also run collectstatic remotely, so I'm not sure what would cause that.
You can set the environment variable DJANGO_SETTINGS_MODULE so you don't need specify --settings everywhere:
heroku config:set DJANGO_SETTINGS_MODULE=project.settings.prod
First, if you are going to serve static via CloudFront, you can use custom origin and always use local STATIC_ROOT. Actually it has some advantages over S3 source, eg gzip support.
Another good thing you can do is to have environment dependent settings in a separate file and then import it in settings.py, eg:
local_settings.py (not in project repository, yet you can have local_settings.py.example):
#environment dependent settings
DATABASES = { .. }
CACHES = { .. }
STATIC_ROOT = 'your_path/static'
settings.py:
import local_settings
I've just replied a similar question on Upload Media from Heroku to Amazon S3. If you customise your settings to take in account environmental vars, you can use filesystem storage backends locally and S3 storage backends when pushing to Heroku. This will collect and upload your static files when your slug is compiled.