Getting Started with ConfigMaps

The Need of the Hour

Note: ConfigMaps allow us to keep configurations separate from application images. Such separation is useful when other alternatives are not a good fit.

Almost every application can be fine-tuned through configuration. Traditional software deployment methods fostered the use of configuration files. However, we won’t discuss those methods. Instead, we’ll look at advanced, distributed, and immutable deployments through Kubernetes schedulers.

Although newer technologies may often require new processes and fundamentally different architecture, we can’t just throw away everything we have and start completely fresh. We’ll have to try to balance new principles and legacy needs.

If we were to start developing a new application today, it would be distributed, scalable, stateless, and fault-tolerant. Those are some of today’s needs. While we might question how many of us know how to design an application with those quality attributes in mind, hardly anyone would argue against having any of them. What is often forgotten is the configuration. Which mechanism should your new application use to configure itself? What about environment variables?

Note: Environment variables fit well into distributed systems. They are portable and easy to define. They are the ideal choice for the configuration mechanism of new applications.

However, in some cases, the configuration might be too complex for environment variables. In such situations, we might need to fall back to files (hopefully YAML). When those cases are combined with legacy applications, which are almost exclusively using file-based configuration, it is evident that we cannot rely only on environment variables.

When a configuration is based on files, the best approach we can take is to bake the configuration into a Docker image. This means that we’re taking the fully-immutable approach. Still, that might not be possible when our application needs different configuration options for various clusters (e.g., testing and production).

We don’t want to convert this into a discussion that ends with “you do not need a different configuration for different environments.” Just assume that you might have an excellent reason for something like that. In such a case, baking configuration files into images will not do the trick. That’s where ConfigMaps come into play.

ConfigMaps

ConfigMaps allow us to “inject” configurations into containers. The source of the configurations can be files, directories, or literal values. The destination can be files or environment variables.

Note: ConfigMaps take a configuration from a source and mount it into running containers as a volume.

That’s all the theory you’ll get up front. Instead of a lengthy explanation, we’ll run some examples and comment on the features we experience. We’ll learn by practice instead of learning by memorizing theory.

For setting a ConfigMap, we’ll use the following command after creating the cluster:

kubectl config current-context 

However, for practicing the code on the platform, context is already configured for you.