sedkis
commented
5 years ago 1) I updated the readme to use the new secret TYK_GW_SECRET instead of the deprecated TYKSECRET.
2) i updated the flow to maintain backwards compatibility as per @excieve comment above.
Problem
Currently, many users have been running into circles trying to understand why their Gateway secret is not working. It's because the entrypoint script is overriding the tyk.conf secret with an environment variable. If the environment variable doesn't exist, the entrypoint script uses the default license.
This flow is causing users problems because it is not intuitive.
First change
If the entrypoint script doesn't detect an environment variable, it will read the one from the tyk.conf and put it into the environment variable, instead of automatically assigning the default dev license. This ensures backwards compatibility for users who are using env variables and not the tyk.conf secret
3 cases i can think of to use this docker image: 1) using an env variable for the secret - will continue to work as normal. the entrypoint script will see that there is an env variable set and will not overwrite it 2) no env variable, secret not set in tyk.conf - the entrypoint script will set the env variable to the default license, which is the same behaviour as before these changes.
the third case is the one that is causing users problems and the point of this pull request: 3) no env variable, secret is set in tyk.conf - the entrypoint script will set the env variable to the secret in the tyk.conf
Second change
I also got rid of the env variable TYKLISTENPORT because this image was merely exposing the port. Which actually does nothing unless the user runs the docker container with the "-p" flag and explicitly opens up that port as well. It is mostly there to tell users that they have to remember to expose the port when running the container.