-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: proposal of management of .env* parameters files in Symfony+Docker way #85
Conversation
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 |
db9ef52
to
56950eb
Compare
…problem of lower case keys
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.*
…tation by file content (usefull for Docker secrets)
a36f402
to
4fe97a5
Compare
aa18e5c
to
741b94b
Compare
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
b81550a
to
e1145e4
Compare
…cit .env* load can be used in makefile
abandonned, to complex according project management and difficult to "non docker developers" to maintain |
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