Allow overriding of service environment variables
Closed this issue · 4 comments
I am looking to use this extension to improve the debugging experience of our existing services. Me and a few other developers use WSL for development. After reading the docs about the suggested way to enable this workflow, we didn't really like the idea of having to update all our microservices to use environment variables for getting host names and ports, just to enable a handful of developers, so we came up with another solution.
We run kubefwd on our WSL instance, and then lie to BridgeToKubernetes and set useKubernetesServiceEnvironmentVariables
to true
. Our apps can then continue to use the host names that we set in our config files instead, rather than relying on env variables.
An issue has come up though, where we have the need to override one of the service environment variables for a specific application. If we set a value for it in the KubernetesLocalProcessConfig.yaml
file, it gets overridden.
Would it be possible to make the config file take precedence over the service environment variables, or alternatively add a way to disable the behaviour of adding those env variables so that that value won't get overridden?
@adibradfield, thank you for this issue. This is a great out of the box way of using bridge :) Yes we will add this to our planning and loop our engineer and PM to discuss how to enable this scenario for your team. For timeline, just keep in mind we are a small team. We also welcome contributions, so please feel free to be involved on the discussion and even implementation if you are up for it :)
Some dev notes:
Code where environment variables are populated is here:
Some implementation ideas:
- One option would be to pass user defined environment variables here and ensure they take precedence.
- Other option would be having an alternate mode to useKubernetesServiceEnvironmentVariables for WSL that assumes user has set up kubefwd and hence bridge can skip setting up environment variables.
Currently leaning towards second option since it seems more targeted to the scenario.
Cc: @hsubramanianaks, @Tatsinnit, @Eneuman as fyi. Thoughts and input welcomed :)
@adibradfield Any input on the above thoughts from Elena, ex: these implementation Ideas will help your situation?
Example file for Idea#1
KubernetesLocalProcessConfig.yaml
apiVersion: v1
kind: Service
environment:
variablesOverride:
servicename_SERVICE_HOST: 'myhost'
servicename_SERVICE_PORT: '8080'
Example file for Idea#2 , if enableFeatures.environmentVariablesOverride is present in this file , then b2k will not generate environment variables or else it would generate if useKubernetesServiceEnvironmentVariables from input is true.
KubernetesLocalProcessConfig.yaml
apiVersion: v1
kind: Service
enableFeatures:
- environmentVariablesOverride
Also, just curious why are you using kubefwd + b2k combination? is it because you want to access/debug services/pods across different namespaces? Trying to understand why. Thanks. Please let us know.
@adibradfield Hi Adrian - Any update on the above approach? please let us know. Thank you.
@adibradfield Please reopen this issue if you need further assistance on this. Also, if you have bandwidth, you can always contribute to this feature request. Thank you.