Kubernetes ConfigMaps and Secrets Part 2

Sandeep Dinesh
Aug 8, 2017 · 4 min read

This is a continuation from Part 1.

While environment variables are great for small bits of information, sometimes you might have a lot of data that needs to be passed to your app. A common solution is to group this data into a file, and have your app read from this file.

Kubernetes let’s you mount ConfigMaps and Secrets as files. Unlike environment variables, if these files change the new files will be pushed to the running pods without needing a restart, so they are a lot more powerful. You can also map multiple files to a single ConfigMap or Secret, and mount them all at once as a directory!

Read from a file

Let’s modify our code from Part 1 to read from files instead of environment variables.

First, create a two subdirectories called “config” and “secret”, and config.json and secret.json files with the data we used in part one:

mkdir config && mkdir secretecho '{"LANGUAGE":"English"}' > ./config/config.jsonecho '{"API_KEY":"123-456-789"}' > ./secret/secret.json

Now, edit the code so it reads in these files instead of environment variables.

Important: This code will re-read the file on every request. If you read the file once when the program starts, updates to the file will not be captured and you will need to restart the container to update the files. A common pattern that is more efficient that re-reading the file every time is to use a file watcher that will reload the file only when it changes.

Mount the files using Docker volumes

The first step is to test everything works by using Docker volumes to simulate the ConfigMaps and Secrets.

Rebuild the container:

docker build -t envtest .

After building the container, run it with the following command:

docker run -p 3000:3000 -ti \
-v $(pwd)/secret/:/usr/src/app/secret/ \
-v $(pwd)/config/:/usr/src/app/config/ \
envtest

This will run the Docker container, and mount the data folders into the container.

Note: the onbuild container that is used for the base image puts the code into the /usr/src/app directory. That is why the folders are mounted there.

If you visit localhost:3000 the container should be serving traffic.

Because the file is mounted into the container and the code re-reads the file on every request, you can change the files and see the change without restarting anything!

For example:

echo '{"LANGUAGE":"Spanish"}' > ./config/config.json

Creating the ConfigMap and Secret

Create the Secret from the file

kubectl create secret generic my-secret \
--from-file=./secret/secret.json

Then create the ConfigMap from the other file

kubectl create configmap my-config --from-file=./config/config.json

You can check that these are created with the following commands:

kubectl get secret

And

kubectl get configmap

Using ConfigMaps and Secrets as files

The final step is using creating a deployment that will use the ConfigMap and Secret as a file instead of an environment variable

Note: Remember you need to update and push the Docker image in your registry to use the new code. You can do that with this command if you are using Google Cloud.

gcloud container builds submit --tag gcr.io/$(gcloud config list project --format=text | awk '{print $2}')/envtest:file .

In your deployment YAML, you can use the ConfigMap and Secret as a volume. This will automatically mount them as a directory in your container, just like with Docker.

Notice that the Secret and ConfigMap are mapped to volumes, and these volumes are used in the volumeMount section of the container spec.

Updating with no downtime!

Unlike Part 1’s environment variables, volumes can be dynamically remounted into running containers. This means that new ConfigMap and Secret values will be available to the container without needed to restart the running processes.

For example, change the language to Klingon and update the ConfigMap.

echo '{"LANGUAGE":"Klingon"}' > ./config/config.jsonkubectl create configmap my-config \
--from-file=./config/config.json \
-o yaml --dry-run | kubectl replace -f -

In a few seconds (up to a minute depending on the cache) the new file will be pushed to the running containers automatically!

If you want to update the secret, you can follow the same process:

echo '{"API_KEY":"0987654321"}' > ./secret/secret.jsonkubectl create secret generic my-secret \
--from-file=./secret/secret.json \
-o yaml --dry-run | kubectl replace -f -

Note: These updates are eventually consistent. It is possible that some containers get the update before others, creating inconsistencies in your deployments. If this is an issue, do not use the auto-update feature. Instead, create a new ConfigMap or Secret, and update or create a new Deployment to use the new one.

Google Cloud - Community

Google Cloud community articles and blogs

Google Cloud - Community

A collection of technical articles and blogs published or curated by Google Cloud Developer Advocates. The views expressed are those of the authors and don't necessarily reflect those of Google.

Sandeep Dinesh

Written by

Google Cloud - Community

A collection of technical articles and blogs published or curated by Google Cloud Developer Advocates. The views expressed are those of the authors and don't necessarily reflect those of Google.

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store