I started with a fresh TYK install and no external conf file and I would like to customize the TYK_DASHBOARD_DOMAIN variable in the setup.sh script but it doesn’t work.
It was before my changes. I didn’t change the setup.sh content except an echo $OK to see the cUrl response after this line OK=$(curl --silent --header "Authorization: $USER_AUTH" --header "Content-Type:application/json" --data "$API_PORTAL_DATA" -X PUT http://$DOCKER_IP:3000/api/apis/$API_PORTAL_ID 2>&1)
The url prefixes for the three (portal) API still are http://localhost instead of http://tyk_dashboard (because of the error ?)
Thank you for the new quick start guide. There is missing the cUrl to create portal access ?
Setting those values in setup.sh will break the demo. The demo is designed with very specific hostnames in mind, changing them requires changing more than just the variables in the setup file.
The setup script just initialises your stack so you can try it with the values that have been provided. If you deviate from those, it will break.
I’m trying to write a stackfile with the minimum environment variables to get tyk working but when i compare the excel file here : https://tyk.io/wp-content/uploads/2016/11/Gateway-Environment-Vars.xlsx and conf values in tyk.conf, tyk_analytics.conf or pump.conf some values are missing.
Or, some values are nested and i don’t know how to inject them via environment variables, like :
For example, in : pump.conf :
pumps
uptime_pump_config
How, can i translate it in environment variables ?
There are special variables for the pumps, we recommend for the pump to have a file included with your deployment, and then set the DB servers using these variables:
I’m afraid for the pump, because the pumps list is a dynamic key/value object, the environment variables will not work like that.
For the pump you’ll need a file, and then use the special variables I mentioned earlier to set the mongo and redis connection strings.
But you can’t set the sub-keys of a named pump config (e.g. “mongo”, “mongo_aggregate” etc.) because we don’t register them with the environment config handler since we don’t know if they exist (it’s dynamic, after all).
It’s something we’re looking to improve, but it will take a while
Thanks for letting us know - it’s something we’ll need to fix in a major version release as it will break backwards compatibility.
For the pump, because we have a blanket environment parser, it isn’t quite that easy to add the extensions, instead extensions have their own prefixes so they can be managed independently, but they still need to be registered in a file.
One way to manage this might be to build a new container based off of ours as a base image and then bake Ina. Config file to override the settings dynamically with the environment variables.