(This is not a problem or bug description, just a reflection on and curiosity about the various ways one can configure the stack.)
The Things Stack can be configured using command-line flags, environment variables, or configuration files.
While i can see that some methods might be better suited for experimental runtime changes (command-line flags), others for permanent settings (environment, files),
do you see a general preference for one method over the others, or is it just a matter of taste? Is there a best practice?
As with everything in Computer Science, the answer is: it depends. For some people it’s just preference, for others it will depend on the infrastructure they’re deploying a network on. In our documented deployments we typically use a combination of a config file and environment variables:
In the Docker-Compose deployment from our documentation, most configuration is done in a configuration file, but some overrides for the specific environment (pointing to databases and Docker volumes) are done with environment variables.
In our AWS EC2 deployments such as the Launcher on the AWS Marketplace, CloudFormation writes pretty much everything to the config file.
Our AWS ECS deployments use a combination of a dynamic configuration file that is generated from several parameters in AWS Parameter Store, and environment variables that are set by CloudFormation for the specific environment.
Thanks, @htdvisser - very useful comments. It was actually during the work of adapting your script to a slightly different deployment (CentOS, postgres), and comparing to other guides, that i came to think about it.
The approach seems to make sense - config files for all that is stable across deployments, environment for everything that s specific to a deployment.
And, i remain curious what other approaches people might be using.