Introduction to ConfigMaps

Most business applications have two components:

• The application

• The configuration

Simple examples include web servers such as NGINX or httpd (Apache). Neither is much use without a configuration. However, as soon as we add a configuration, they become very useful.

In the past, we packaged the application and the configuration into a single easy-to-deploy unit. We brought this pattern with us as we moved into the early days of cloud-native microservices. However, it’s an anti-pattern, and modern applications should be decoupled from their configurations. Doing this brings the following benefits:

• Reuse

• Simpler development and testing

• Simpler and less-disruptive changes

We’ll explain all these and more as we go through the chapter.

The big picture

As previously mentioned, most applications comprise an application binary and a configuration. Kubernetes lets us build and store them as separate objects and bring them together at run time.

Consider a quick example.

Imagine you work for a company with three environments:

• Dev

• Test

• Prod

You perform initial testing in the dev environment, more extensive testing in the test environment, and apps finally graduate to the prod environment. However, each environment has its own network policies and security policies, as well as its own unique credentials and certificates.

You currently package application binaries and their configurations together in the same image, forcing you to perform all of the following for every application:

• Build three images (one with the dev config, one with the test config, and one with prod)

• Store the images in three repositories (one for the dev image, one for test, and one for prod)

• Run different versions of each app in each of the three environments (the dev app in the dev environment, test in test, prod in prod)

Every time you change the configuration of any app, even a small change like fixing a typo, you have to build, test, store, and re-deploy three images — one for dev, one for test, and one for prod.

It’s also harder to troubleshoot and isolate issues when every update includes the app code and the config.

What it looks like in a decoupled world

Imagine you work for the same company, and they ask you to build a new web app. However, the company now decouples applications so that app code and configurations are stored separately.

You decide to base the new app on NGINX and create a hardened NGINX image that other teams and applications can use by applying their own configurations. This means:

• You only build a single image that you’ll use across all three environments

• You only store and protect that single image in a single repository

• You run the same version of this image in all your environments

To make this work, you build a single image containing nothing more than the hardened NGINX with no embedded configuration.

You then create three configurations for dev, test, and prod that you’ll apply at run time. Each one will configure the NGINX container with the policy settings and credentials for the correct environment. Other teams and applications can reuse the same hardened NGINX image for their own web apps by creating their own configurations.

In this model, you create and test a single version of NGINX, build it into a single image, and store it in a single repository. You can grant all developers access to the repository as it contains no sensitive data, and you can push changes to the application and its configuration independently of each other. For example, if there’s a typo on the homepage, you can fix it in the configuration and push that to existing containers in all three environments. You no longer have to stop and replace every container in all three environments.

Let’s see how Kubernetes makes this possible.