Lesson 3: Updating with ConfigMaps
In lesson 2 you learnt how to update the Kubechaos app by making changes to the source code and then easily redeploying the app. In this lesson we will show you a way of updating your application outside of modifying the code directly. This allows you to decouple environment specific configuration from your container images, leading to ease of update and portability.
What is a ConfigMap
A ConfigMap is a Kubernetes API object which stores data in key-value pairs. They are used for non-confidential data only, for managing confidential data you can use Secrets. Further reading on secrets can be found here.
Pods can use the information in ConfigMaps either as environmental variables or the ConfigMap can be mounted as a volume. In this tutorial we will go through both cases and how they can be applied.
Configuring the Style with Environmental variables
In web applications the style is often configured independently of the application code. Kubernetes offers an easy and useful way to update pods from ConfigMaps without having to redeploy anything or rebuild the container.
We currently have a configMap running in our cluster. You can view it either through the minikube dashboard by clicking on ConfigMap in the side bar, or by running
kubectl describe configmap kubechaos-style
This ConfigMap controls the style of the website. We can change the colours and fonts without needing to change the underlying software of the container as you did in Lesson 2.
We are now going to change the colors and border of the web application. To edit the ConfigMap type the following into a terminal
kubectl edit configmap kubechaos-style
Change the following variables:
bg_color: white
font_color: black
border_color: black
border_size: 4px
border_style: dashed
⚠️ Note you will need to use specific variables for colors: - they can be in hex rgb format e.g. #000000 or #0000ff - or they can be in css names e.g. black or blue
Refresh your web browser. What has happened?
You will have noticed that your changes have not been applied, the styling remains the same. To get the colours to change run the following:
kubectl rollout restart deployment kubechaos
Refresh your web browser, what do you see now?
Explanation
The variables that you edited in the ConfigMap are applied as environmental variables. To get the pod to pick up on it's new environment it needs to be remade. The quickest way to restart everything is to use the kubectl rollout restart
command we used above.
We will now look at manifest.yml
. Please open up this file and scroll to the block at line 22, to line 44. In this part of the deploymnet we set the env
section of the container with values from the ConfigMap.
spec:
containers:
- name: app
image: local/kubechaos:v1
ports:
- containerPort: 3000
env:
- name: BG_COLOR
valueFrom:
configMapKeyRef:
name: kubechaos-style
key: bg_color
- name: FONT_COLOR
valueFrom:
configMapKeyRef:
name: kubechaos-style
key: font_color
- name: BORDER_COLOR
valueFrom:
configMapKeyRef:
name: kubechaos-style
key: border_color
- name: BORDER_SIZE
valueFrom:
configMapKeyRef:
name: kubechaos-style
key: border_size
# can you edit this to add the BORDER_STYLE env variable from the ConfigMap
Extra
In manifests.yaml
can you add the value of border_style
to the enviromental variable BORDER_STYLE
to change the border style, through the ConfigMap?
In this section we injected variables from the ConfigMap into the pod as environmental variables to make changes without having to rebuild the image. This use case is ideal for applications that read configuration through environment variables. This method is straightforward and doesn't require file handling. You have to restart the container in order for any ConfigMap changes to take effect.
In the next section we will look at mounting our configMap to the container as a volume. This method is used when applications are expecting configuration files rather than environmental variables.
Configuring the style with a css file
Usually a website's style is configured through a stylesheet provided as a .css
file, rather than with environmental variables. In this section we are going to look at another way to use ConfigMaps, mounting them as volumes into the pod.
If you look at the ConfigMap we have deployed on our cluster either through the Minikube Dashboard or by running kubectl describe configmap kubechaos-style
you will see that there is a definition of a css file in the ConfigMap:
style.css:
----
body { font-family: 'sans-serif';
text-align: center;
margin-top: 5rem;}
Now let's edit these variables in the ConfigMap keeping the structure of the file intact:
⚠️ Note you will need to use specific variables for
font-family and
text-align: -
text-aligncan be
center,
right,
left-
font-familyhas to belong to the websafe fonts e.g.
serif,
arial,
garamond`
kubectl edit configmap kubechaos-style
Refresh your browser? What happens now? You will see the changes you made will be applied immediately on refresh without restarting the deployment.
Explanation
Here we are mounting a file as a volume into the pod. The file is being written by the values in the in the ConfigMap. When we change the values they are immediately picked up by the pod without it being restarted. If you open the manifest.yml
and scroll to line 44 to 54 you will see:
``` container: ... volumeMounts: - name: style-env mountPath: "/src/public/" readOnly: true volumes: - name: style-env configMap: name: kubechaos-style items: - key: "style.css" path: "style.css"
This section of the deployment creates a volume called `style-env` and then mounts it as a volume in the container. This volume contains the `style.css` file and is mounted on the path the application expects.
To see the mainfest of the original ConfigMap (before our edits) you can scroll down to line 73 in `manifests.yml`:
apiVersion: v1 kind: ConfigMap metadata: name: kubechaos-style data: bg_color: white font_color: black border_color: black border_size: 4px border_style: dashed
style.css: | body { font-family: 'sans-serif'; text-align: center; margin-top: 5rem; }
``` For a production system you can version control your changes to a ConfigMap as a manifest and apply it to your cluster.