As @Harith mentioned, the use of secrets simplifies deployments in various environments using environmental variables. To load in a secret directly use:
$ kubectl create secret generic < NAME OF SECRET > --from-literal=< KEY >=abc123!:?
NOTE! This will put the secret in the Default namespace, add a namespace flag for specific resources e.g.:
$ kubectl create secret generic mongodbsecret --from-literal=mongoUser=abc123!:? -n mongoNamespace
You can then reference this secret in the deployment.yml or pod.yml or wherever you put your image for deployment on the kubernetes cluster.
env:
- name: MONGO_INITDB_ROOT_USERNAME <name of the env var in the code>
valueFrom:
secretKeyRef:
name: mongodbSecret <NAME OF SECRET>
key: mongoUser <KEY>
However, if all you need is to change 'development' to 'production' you could put an environment var directly in the (deployment).yaml.
env:
- name: NODE_ENV
value: production
You can also update the Jenkinsfile to send in the environment by for instance:
def resource_env = BRANCH_NAME == 'master' ? 'production' : 'development'
sh "kubectl set env ${kubeImageName} NODE_ENV=${resource_env} --namespace ${kubeNamespace}"
On your current pipeline idea: The safest place for sensitive env vars would be putting it in kubernetes in a secret in your situation. However, for simple selection of deployment environments then using a Jenkinsfile simplifies things a bit like 'prod' vs 'dev'. Putting sensitive, variable or private things on git is a bad idea. Keep your docker images precise and task-orientated.
Hope that helps