feat: proposal of management of .env* parameters files in Symfony+Docker way #85
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The proposition is to managed .env files according to Symfony standard
- we load .env.template as default values. In it, APP_ENV=dev is declared
- then override with content of .env.local if exists. This file is not index in git, we can overload APP_ENV=test by example
- then override with content of .env.${APP_ENV} if exists. This file contains default sepcific to APP_ENV env (dev/test/prod) in addition to common default values in .env.template
- then override with content of .env.${APP_ENV}.local if exists. This file is not indexed in git.
For compliance with docker standard, .env is reserved to store the merged result of all variables
So when all files has been parsed, the result is written in .env and reloaded from .env in bloom.config
All keys are transformed to lower case
ATTR=VaLue will give => settings.attr:VaLue
To assure a minimal documentation of parameters, as Symfony standard in .env.dist
The extracted values in all theses files MUST BE present in .env.template
So for adding a new parameter, you MUST declare it in .env.template with a default value
If not, this new parameters won't be available in python scripts
To access settings
```
from bloom.config import settings
print(settings.db_url)
print(settings.postgres_user)
```
|
En terme d'amélioration, on pourrait gérer la APP_ENV via arguments de lancement de l'application plutôt qu'en le surchargeant dans .env.local. Cela permet de lancer plusieurs instances dans des environnements différents sans conflits de lecture/écriture au sein du même répertoire. |
|
Là je génère un fichier .env qui contient le résultat compilé pour utilisation avec Docker --env-file ./.env mais j'aime pas trop cette solution car si on lance deux applis dans deux modes différents, le .env va être modifié par la dernière lancé. Ce n'est pas bon mais tant qu'on utilise qu'un mode y a pas trop de souci |
rv2931
force-pushed
the
env_management_proposal
branch
from
db9ef52
to
56950eb
Compare
…problem of lower case keys
rv2931
force-pushed
the
env_management_proposal
branch
from
71c02ec
to
614deb4
Compare
…APP_ENV and .env.* files
…ocker compliance --env-file + keep .env.template case for parameters The bloom.config already knows extract and override key/value pairs from .env.* files based on .env.template default key/value pairs The idea here is to add env vars extraction and override pre existing/extracted values from files This is compliant with Docker standard but also with standard deployement: - for the same key/value, env value is prioritay to file value - if no env value, then file value - if no file value, then default value from .env.template
…ferent then .env.*
rv2931
changed the title
…tation by file content (usefull for Docker secrets)
rv2931
force-pushed
the
env_management_proposal
branch
from
a36f402
to
4fe97a5
Compare
rv2931
force-pushed
the
env_management_proposal
branch
from
aa18e5c
to
741b94b
Compare
rv2931
force-pushed
the
env_management_proposal
branch
3 times, most recently
from
d1efe35
to
b81550a
Compare
dev: source .env; source .env.local; source .env.dev; source .env.dev.local; export APP_ENV=dev; docker compose -f docker-env\docker-compose-base.yml -f docker-env\docker-compose-dev.yml up test: source .env; source .env.local; source .env.test; source .env.test.local; export APP_ENV=test; docker compose -f docker-env\docker-compose-base.yml -f docker-env\docker-compose-test.yml up prod: source .env; source .env.local; source .env.prod; source .env.prod.local; export APP_ENV=prod; docker compose -f docker-env\docker-compose-base.yml up app (only app) all configurations files .env, .env.local, .env.dev|test|prod, .env.dev|test|prod.local are systematically mounted as volumes in all docker configuration, they load (source) before docker compose to services that are using ENV var like posgtrds (i.e: POSTGRES_HOSTNAME) to ge tconsistant configuration file in docker et launch variable for docker services. Their use is totallement conditionned by APP_ENV value in the .env.local file but is override if we export it in environment variable
rv2931
force-pushed
the
env_management_proposal
branch
from
b81550a
to
e1145e4
Compare
…cit .env* load can be used in makefile
Merged
|
abandonned, to complex according project management and difficult to "non docker developers" to maintain |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The proposition is to managed .env files according to Symfony standard
For compliance with docker standard, .env is reserved to store the merged result of all variables So when all files has been parsed, the result is written in .env and reloaded from .env in bloom.config
All keys are transformed to lower case
ATTR=VaLue will give => settings.attr:VaLue
To assure a minimal documentation of parameters, as Symfony standard in .env.dist The extracted values in all theses files MUST BE present in .env So for adding a new parameter, you MUST declare it in .env with a default value If not, this new parameters won't be available in python scripts
To access settings
To overload a default .env value, you have to create a .env.local file with the new key/value pair, it will override the default value at runtime