3 ms·

> webapp declares an env_file from which to pick up env vars. This is important because we configure a lot of our applications with environment variables so tha

> webapp declares an env_file from which to pick up env vars. This is important because we configure a lot of our applications with environment variables so that the same docker image can run in different environments, taking inspiration from 12-factor apps. Keep in mind that your environment variables can be learned by inspecting the image. So if you make that image public, those envs are visible. As far as i understand, this is analogous to committing your passwords to source control and should be a consideration.

throway21312 10y ago
What would the correct methodology be?
jasonmp85 10y ago
Huh? I mean, sure, you can probably figure out the _names_ of the environment variables expected by the code of the image, but the image itself doesn't have the values for those variables. Environment files are—unless I'm missing something—a run-time consideration. You provide the an env-file you have locally to connect to your development images, etc., and could deploy (possibly) the same image elsewhere, with a different env-file. But the env-file values are not baked into the image.
- Feuilles_Mortes 10y ago
  This is correct - I just set this up today.
- girvo 10y ago
  They _can_ be baked into the image via build-args or the "ENV" Dockerfile syntax, but as your Dockerfile is committed to git normally this has the same dramas, of course! You're completely correct, but I wanted to mention that it was possible :)
  - droningparrot 10y ago
    Build-args and ENVs are not the same thing. Build-args use the ARG syntax and are baked in during docker build. ENVs are not baked in; the values are passed in during docker run or docker exec.
    - girvo 10y ago
      You are correct, they are not the same thing; however they can be combined to bake in an ENV to an image as a default value for a given ENV key, controlled at "docker build".

throway21312 10y ago

What would the correct methodology be?

jasonmp85 10y ago

Huh? I mean, sure, you can probably figure out the _names_ of the environment variables expected by the code of the image, but the image itself doesn't have the values for those variables. Environment files are—unless I'm missing something—a run-time consideration. You provide the an env-file you have locally to connect to your development images, etc., and could deploy (possibly) the same image elsewhere, with a different env-file. But the env-file values are not baked into the image.

Feuilles_Mortes 10y ago
This is correct - I just set this up today.
girvo 10y ago
They _can_ be baked into the image via build-args or the "ENV" Dockerfile syntax, but as your Dockerfile is committed to git normally this has the same dramas, of course! You're completely correct, but I wanted to mention that it was possible :)
- droningparrot 10y ago
  Build-args and ENVs are not the same thing. Build-args use the ARG syntax and are baked in during docker build. ENVs are not baked in; the values are passed in during docker run or docker exec.
  - girvo 10y ago
    You are correct, they are not the same thing; however they can be combined to bake in an ENV to an image as a default value for a given ENV key, controlled at "docker build".