Figure out what we're doing with environment variables in docker for development

[cbeer]

We have a couple approaches to environment variables in the docker-compose file for this project.

• 1) Putting them inline: https://github.com/sul-dlss/dlme/blob/main/docker-compose.yml#L12-L26
• 2) Loading them from a .env file: https://github.com/sul-dlss/dlme/blob/main/.env
• 3) Setting them in the Dockerfile: https://github.com/sul-dlss/dlme/blob/main/docker/Dockerfile#L16-:L18

There's probably an opportunity to agree on a consistent approach, or at least document how to choose.

[thatbudakguy]

here's the approach in my head currently:

• things that need to be used at build time go in the Dockerfile because the other methods won't work in that context. not sure if we have any of these left (maybe BUNDLER_VERSION?)
• things that should be the default for all builds go in the Dockerfile; e.g. RAILS_LOG_TO_STDOUT=true as a best practice. set it once and bake it in. you can override it via the docker-compose.yml if you want.
• things that are an implicit default for a particular build go in the Dockerfile; e.g. we always want RAILS_ENV=development for the development image and RAILS_ENV=production for the prod image. you can override it via the docker-compose.yml if you want.
• everything else goes in the docker-compose.yml file because it's better to be explicit and have them all listed in one place. if two services in the compose stack need the same envvar (for example, SOLR_URL=http://solr:8983/solr/dlme), just write it out in both places.
• we don't use the .env file because it's a third file (in addition to the Dockerfile and docker-compose.yml) and it promotes sharing state between containers.

related to this is the assumption that we should aim to bake in as many envvars as possible in the Dockerfile based on the target environment, so that the compose file basically just wires the services together. hopefully everything in the .env file can be migrated out and we can reassess the minimum envvars actually needed for the services to communicate.

[corylown]

We can potentially close this issue because we plan to move the web application on premise, but we might want to address this if we plan to continue using docker for development.