-
Notifications
You must be signed in to change notification settings - Fork 2.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Kubernetes extension: Support env vars from secrets with a prefix #38604
Comments
Seems reasonable to me! WDYT @iocanel? |
Hi @wpernath, can I get this one or do you want to work on this issue? |
@mcruzdev, please, please take it. -- Thank you! |
Thank you @wpernath! |
@mcruzdev: It's possible that this needs to be implemented in dekorate first. Would you like to give it a try? |
Hi @iocanel surely, I will try! |
Hi @iocanel, I created the issue on https://github.com/dekorateio/dekorate repo, I will start to work on this tomorrow, thank you! |
Description
Right now you can apply a Secret (or ConfigMap) as environment variables like this:
quarkus.kubernetes.env.secrets=my-secret
This would map all keys of the Secret (or ConfigMap) to the environment of the Kubernetes deployment manifest:
However, especially when you're dealing with more than - perhaps - one datasource, it would be great to specify also a prefix. Kubernetes supports adding a prefix to imported keys from Secret / ConfigMap.
If
my-secret
contains a key calleduser
it would be mapped toDB1_user
, which you then could use to specify your datasource properties inapplication.properties
:It would be great if Quarkus could allow the specification of a prefix in
application.properties
for example by using this grammar:quarkus.kubernetes.env.secrets=my-secret[DB1_],my-other-secret[DB2_]
Or by introducing another sub key of
env
calledprefix
:quarkus.kubernetes.env.prefix.my-secret=DB1_
Implementation ideas
No response
The text was updated successfully, but these errors were encountered: