See Below yaml file, it looks like we have to build this path into docker image in order for the dynamic config file to be loaded.
How do we provide our own dynamic config files into docker image versions like temporalio/auto-setup:0.23.1 without touching the code?
If your end goal is to modify Temporal configs but there is currently no exposed env variable for it, here’s a workaround, but it’s not a long term solution. You can use a docker-compose file where you change the entrypoint to a custom script:
#!/bin/sh
# overwrite postgres password using docker secrets
export POSTGRES_PWD=$(egrep -v '^#' /run/secrets/db_password)
# add code here to modify temporal configs, for example you can use sed
# sed -i "/global:/a \ \ \ \ tls:" /etc/temporal/config/config_template.yaml
source /docker-entrypoint.sh /bin/bash -c /start.sh
Temporal uses the dockerize tool on the config_template.yaml file, so you can use the entrypoint to add your own env variables and then specify them in your docker-compose file. I hope this helps.
Hey @Steven_Sun,
If the question is ability to pass in custom path to dynamic config file path then we already support it through DYNAMIC_CONFIG_FILE_PATH environment variable. You can set this environment variable with the docker image produced by Temporal to customize the location of your dynamic config path.
To provide a full out of the box experience for dynamic through helm chart requires some investigation and potentially some more work on our side. I have issue #46 to track this on our end.
Thanks Samar. This requires us to have way to put our file into the already built docker image so we can overwrite the file inside the container, for example we need to have a dynamic config file and then somehow when the docker image is build it needs to take our file instead of the default one. But when the image is already built there’s no easy way for us to have a new file build into the docker image except docker cp which I want to avoid.
If for scaling factor, can we just expose some scaling handles like task read/write partition? that would be easier for people to scale right?
Let me know if I missed anything.
I found another simpler way to do this. You can mount a file at /etc/temporal/config/base.yaml inside the container, temporal picks that up first, and then the generated docker.yaml (which gets generated using environment props via config_template.yaml)