Join GitHub today
Feature: Support using environment variables inside deployment yaml file #52787
Is this a BUG REPORT or FEATURE REQUEST?: FEATURE REQUEST
What happened: When you write a deployment yaml file, everything must be specified statically. In cases where something is not specified at time of writing, the only choice is using a 3rd-party tool and use yaml file as a template which will later be processed by the tool to replace some markers with actual values. This is not efficient.
What you expected to happen: Deployment yaml file format should support some kind of marker which specifies values which will be provided at the time of deployment via command line arguments (e.g.
How to reproduce it (as minimally and precisely as possible):
Anything else we need to know?: This will make life easier for DevOps.
you can use
Nobody has mentioned
For a small project I put everything in a folder,
Anything ending in
And in my
I face a similar problem with yaml template files that include CPU architecture, such as amd64. I often had to change those manually to arm when deploying on a raspberry pi for testing purposes. One popular example is metrics-server, where amd64 is hard-coded in the yaml:
@daniel-kun I'm going to assume that you're using Go, but i guess that doesn't have to be true for this to work.
apiVersion: extensions/v1beta1 kind: Deployment # ... architecture: amd64
I think there are plenty of tools available for this; it doesn't have to be embedded into
kubctl should enable templates and insertion to avoid DRY(don't repeat yourself)
One simple example are DEV, QA, PROD environments where sanboxing images is mission critical and the image value of containers should vary with arguments.
Another is using similar deployments for minikube development and cloud deployment where the only differences are mounting volumes and replicas
Another example is deploying to a feature branch with less CPU
For the record, the simple solution I settled on was to feed the file through
In practice, I put the replacements into a bash script file, so invocation looks more like:
Which works really well in my Jenkins pipeline. And it's helpful to not depend on any external packages like envsubst in environments where it's not immediately available.
kubectl will never support variable substitution.
Background document: https://goo.gl/T66ZcD
I suggest building an extension for Helm and participating in the Helm v3 discussions. My aim is to make Helm more flexible, to address such cases: https://docs.google.com/presentation/d/10dp4hKciccincnH6pAFf7t31s82iNvtt_mwhlUbeCDw/edit#slide=id.p
Please participate in SIG Apps and the Application Definition Working Group.