The repo contains the following 3 services that are supposed to run in a server:
- synchronizer
- relayer
- archiver
They all follow the same pattern for configuration. They use environment variables that can be loaded from files. The current implementation loads the vars from 3 different places
- a. env var
- b.
.env file in the current directory
- c.
{service_name}/.env
Option c only makes sense when running the service from the root of the repository for testing.
Option b can be useful to run the service in a testing environment.
Option a can be useful to run the service via docker-compose because we can just set the var values in the docker-compose file. I guess for systemd we can also do that in the service file.
Are we happy with this? Or should we do a proper configuration file like regular Unix daemons do?
My thoughts are that env vars + .env file is fine for now, but perhaps I'd remove option c because I think it's misleading and only applies to a development environment. Is anybody relying on option c during development? I personally test the service from it's directory, where I store the .env file, so I'm not using that option.
#150 (comment)
The repo contains the following 3 services that are supposed to run in a server:
They all follow the same pattern for configuration. They use environment variables that can be loaded from files. The current implementation loads the vars from 3 different places
.envfile in the current directory{service_name}/.envOption
conly makes sense when running the service from the root of the repository for testing.Option
bcan be useful to run the service in a testing environment.Option
acan be useful to run the service via docker-compose because we can just set the var values in the docker-compose file. I guess for systemd we can also do that in the service file.Are we happy with this? Or should we do a proper configuration file like regular Unix daemons do?
My thoughts are that env vars + .env file is fine for now, but perhaps I'd remove option
cbecause I think it's misleading and only applies to a development environment. Is anybody relying on optioncduring development? I personally test the service from it's directory, where I store the.envfile, so I'm not using that option.#150 (comment)