In the previous setup we had different settings files in settings folder. These settings where later mounted into the docker container on docker-compose up.
Drawbacks of previous aproach:
- Settings specified in separate files are not secured. Users who can see settings files do also have access to all the "secured" variables.
- Mounting the volume is a bad idea, because we cannot collect static files or create folders in the mounting volume during the docker build.
- Tree structure does not allow to find required settings in a fast way, you have to switch between different settings files.
- During the mount of the settings file, empty files appeared in the git (example.py), which should be deleted after containers are off. Otherwise we have to create empty file in the repository.
How it works:
- In the root of the project we have env file in which all the production variables are saved. In my case ENV file looks like:
DEBUG=False
DB_NAME_DEFAULT=***
DB_USER_DEFAULT=***
DB_HOST_DEFAULT=***
DB_NAME_SUBJECT_MANAGEMENT=***
DB_USER_SUBJECT_MANAGEMENT=****
DB_HOST_SUBJECT_MANAGEMENT=***
ALLOWED_HOSTS=***
AUTH_LDAP_SERVER_URI=***
AUTH_LDAP_BIND_DN=***
AUTH_LDAP_BIND_PASSWORD=***
AUTH_LDAP_SCOPE=***
AUTH_LDAP_PARAM=***where *** are actual settings
- We have 2 yml files used for docker-compose. One is used to run production environment, another for development environment. If you use PyCharm then you can create setup to run either development or production environment.
- Variables of docker-compose-dev.yml (DEBUG and etc) override variables defined in ENV file and enables development settings.
- It is still possible to use local development environment without docker. When you run python manage.py runserver default variables from settings.py are in use.