undefined | Better HN

0 pointsfreedomben1y ago0 comments

I may be unusual, but I much prefer the environment variables in a docker compose file. A .env feels like an anti-pattern to me honestly.

0 comments

3 comments · 1 top-level

Lucasoato1y ago· 2 in thread

This sounds right until you have to version your docker-compose file.

Storing passwords or secrets in git should be avoided; the .env file structure allows you to leave untouched the yaml file. Anybody changing it? Git pull, and you’re ready to go, since you didn’t change the yaml file and you don’t have to substitute secrets again.

freedombenOP1y ago

I don't disagree, but I think you're conflating secrets with environment variables. Yes most secrets are (or should be at least) passed in through env vars, but there's also a ton (in some apps 80% to 90%) of configuration that aren't secrets. I also dislike when people treat every config value as a secret. Secrets require additional overhead and care, and burdening yourself (or another dev or operator) with that in order to tweak a completely non-secretive value is unnecessary and IMHO often counterproductive.

For secrets, a .env file is fine for local dev and docker-compose IMHO. The "hidden file" nature of a .env is a good fit for secrets. (For prod I prefer K8s Secrets or Vault or similar)

inhumantsar1y ago

I've had to debug by tuning multiple vars and compare the results, .env files make this a much cleaner experience especially if the CMS supports a .env file name parameter. I can keep multiple .envs and switch between them easily and know for certain that a change in behaviour isn't due to fat fingering something in the compose file.

In the end it's just personal preference. I get where you're coming from.

j / k navigate · click thread line to collapse