Favor Docker Compose 3.x+ secrets feature over .env files

This is based on the proposal by @japrogramer:

I know this thread is about making .env file more clear for database settings … but I don’t think there should be a .env file at all for docker deployments. Hear me out. If a user really needs to set an enviorment variable it can be done from a compose file. Now for sensitive stuff, I believe that stuff doesn’t even belong in environment variables the reason for this believe: too often are these settings logged out to file and than you have your secrets scattered everywhere… now you have too worry about sanitizing your logs and even worse securing your logs. These is my solution, I have gone and removed the .env file, and only rely on docker secrets.The file, which is encrypted, that i read in as a secret is structured like a json object so i can easily parse in python. Each container has a different set of secrets and they only see what they need to see. I do not have the secrets stored in plain txt anywhere instead I archive the swarm dir in docker which stores encrypted secrets.

#on a manager node
$docker secret create my_secret -
$ tee -
#mind you, my secrets are mounted into my containers from within their respective compose file
$systemctl stop docker.service 
$tar czpvf swarm-dev.tar.gz /var/lib/docker/swarm/

than i rsync that file over an encrypted pipe back home and when i need to restore my secrets i do

$systemctl stop docker.service 
$rm -fR /var/lib/docker/swarm
$tar xzpvf swarm-dev.tar.gz -C /var/lib/docker/swarm/
$systemctl start docker.service 
$docker swarm init --force-new-cluster
$ tee -
#Now all my secrets are back, and available to my swarm. But only to those containers that have been given permission on a per secret basis.

To my mind, there are a few things worth mentioning here.

• Both the local.yml and production.yml Docker Compose configs would need to be upgraded to version: 3.x:
  • as of now, an as-is upgrade is possible since we don’t use any features not supported in 3.x (take extends for example as implied by Version 3 < 3.3 and Version 3.3 specs);
  • according to Compose and Docker compatibility matrix, we would need to switch to
    • Docker Engine 1.13.0+;
    • Docker Compose 1.13.0+.
  • which would require us to
    • upgrade our local host Docker environments;
    • upgrade cookiecutter-django-related remote environments (Travis CI );
    • inform cookiecutter-django community of this change, documenting minimal local host environment Docker stack version matrix.
• Refactor every use of *.env* files should Docker be the client’s environment of preference;
• Ensure consistency and stability for Docker-powered deployments we support (Heroku + currently experimental ELB).

@jayfk @luzfcb @japrogramer what are your thoughts?

[jayfk]

I have a question, is it really popular to have django as something other than an api backend?

I have an answer: yes.

[japrogramer]

Here is how I read in my secrets that i structure in a json format in my config/settings/base.py

with open(env('SECRETS_FILE')) as sec: 
     Secrets = json.loads(sec.read()) 

Than for example.

ACCOUNT_ALLOW_REGISTRATION = Secrets.get('DJANGO_ACCOUNT_ALLOW_REGISTRATION', True)