Now what if you don't want to set up
your environment variables in this way.
You don't want to add them
to your container specification like this.
Instead you wanna have your key value pairs
in a separate file or a separate resource
and therefore for entity in your cluster.
Maybe also such that different containers specs
from different pods
can utilize the same environment variables.
This would be a common use case
and something you can also easily implement with Kubernetes.
For this, I'll add a new YAML file
and that will be my environment.yamlfile.
But the name as always is up to you.
It doesn't have to be named environment.yaml
In this file, we will create a so-called ConfigMap.
For this, we first of all need to set the apiVersion
to v1 again and set the kind to ConfigMap.
This is simply another resource,
another object Kubernetes understands.
And as the name suggests,
it creates a map of configurations.
So a key value pair list basically.
We can and should give it some metadata.
For example a name by which we later can then use it.
We could name this data-store-env
because we'll store the environment variables
for storing data in here.
But ultimately this name is up to you.
Besides the metadata, we then need to add the data
which we do wanna set up in this ConfigMap.
And here we don't do this with a spec but with a data key.
And below that it's super simple.
You have a bunch of key value pairs,
for example, folder and then story,
because I wanna store that story's string
in an environment variable
or in this case, simply a key named folder.
Now this is a ConfigMap
and we could have multiple key value pairs here
if we needed it.
But here I only need one key value payer.
But you can have as many as you need
and you don't have dashes here.
Instead, these are all simply nested key value pairs
inside of this data object here
in this ConfigMap configuration.
Now we can apply this.
We can apply this file the environment.yamlfile.
And this creates this ConfigMap.
As always with kubectl get configmap.
You can see all the ConfigMaps you have.
In this case, one ConfigMap with one piece of data in there.
Now we wanna utilize this ConfigMap
to set the environment variables for this container.
And to do that, the env key here
supports a special syntax so to say.
Instead of setting a value
for your environment variable like this,
you can also replace value with a value from key.
You still need the name because you still need
to define the name of the environment variable
by which it is exposed in your code.
So that's still set up here,
but we now have value from instead of value
and with value from you now can add
a nested ConfigMapKeyRef, which stands for a key reference.
Which allows you to point at a specific ConfigMap
and there in that map a specific data key,
which holds the value you wanna set as a value
for this environment variable in this container.
For this ConfigMapKeyRef takes another nested object
where you specified a name of the ConfigMap.
So in my case, that is this name here, data-store-env,
and then the key name, which value you wanna set as a value
for a story folder in this case.
And in my case to key name is folder.
So I will set folder here as a key name.
And this will now pull the value out of the ConfigMap
and set it as a value for this story folder.
So now if we run kubectl apply-f=deployment.yaml,
We apply the updated deployment, which now pulls the value
for the story folder environment variable
out of that ConfigMap which we created and applied before.
Hence with get deployments,
we see this deployment is up and running,
and if we run get pods
we again, see the old pods are being terminated
and the new pods are getting started.
And of course we can still work with our application
and send our requests there as before.
This all still works because our application didn't change.
We just changed how we get the name off the folder
in which our data is stored.
And as you can see, you can use a ConfigMap
instead of hard coding to value here If you wanna do that.
And that's basically for environment variables already.
With that again, you got full flexibility.
You can use a file which you create as a ConfigMap
and apply, and then get the values from there
or as I showed you before,
you directly add a value here like this.
Both together, of course does not work
you should either set the value here
in your container specification or point at a ConfigMap
from which you wanna get the value.
But with that, we know how to set environment variables.
And of course before that, we also learned
how we can work with volumes.
And that's a lot of important information
about working with data in Kurbenetes clusters.