Support docker secrets for sensitive data

[bj00rn]

Support docker secrets for sensitive data

Support docker secrets for sensitive data

Use corresponding ENV variable with _FILE suffix to read argument from file

Order of precedence is

1. If ENV variable is set, always value of ENV variable as default
2. If ENV_FILE variable is not falsy, use value to read default from file

[nanomad]

@bj00rn Good point, but I'd rather rely on a more generic approach than to extend the already kind of unmaintanable parser.

I'd integrate a library such as python-dotenv and replace EnvDefault to lookup the data from the values coming from there instead.

from dotenv import dotenv_values

config = {**dotenv_values(".env"), **os.environ}  # config = {"USER": "foo", "EMAIL": "[email protected]"}

[bj00rn]

@bj00rn Good point, but I'd rather rely on a more generic approach than to extend the already kind of unmaintanable parser.

I'd integrate a library such as python-dotenv and replace EnvDefault to lookup the data from the values coming from there instead.

from dotenv import dotenv_values

config = {**dotenv_values(".env"), **os.environ}  # config = {"USER": "foo", "EMAIL": "[email protected]"}

Agree. There is a caveat with python-dotenv and docker-compose though since python-dotenv defaults to reading from .env file which is picked up by docker-compose IF the file is present in compose project root. Im guessing a lot of less experienced users will fall into this trap.

Bad example

# docker-compose.yml
services:
  mqtt-gateway
...
  volumes:
    - ./.env # <-- problematic since .env is already read by compose and variables already set globally in the container.

Working example

# docker-compose.yml
services:
  mqtt-gateway
...
  volumes:
    - ./.config.env:/.env

[bj00rn]

#366

[nanomad]

@bj00rn Agreed but I'd rather supply a proper compose instead