Overview

Many applications require configuration using some combination of configuration
files, command line arguments, and environment variables. These configuration
artifacts should be decoupled from image content in order to keep containerized
applications portable.

The ConfigMap object provides mechanisms to inject containers with
configuration data while keeping containers agnostic of OpenShift Container Platform. A
ConfigMap can be used to store fine-grained information like individual
properties or coarse-grained information like entire configuration files or JSON
blobs.

The ConfigMap API object holds key-value pairs of configuration data that
can be consumed in pods or used to store configuration data for system
components such as controllers. ConfigMap is similar to
secrets, but designed to more conveniently
support working with strings that do not contain sensitive information.

You can use the following command to create a ConfigMap holding the content
of each file in this directory:

$ oc create configmap game-config \
--from-file=example-files/

When the --from-file option points to a directory, each file directly in that
directory is used to populate a key in the ConfigMap, where the name of the
key is the file name, and the value of the key is the content of the file.

You can see the two keys in the map are created from the file names in the
directory specified in the command. Because the content of those keys may be
large, the output of oc describe only shows the names of the keys and their
sizes.

If you want to see the values of the keys, you can oc get the object with the
-o option:

Use Cases: Consuming ConfigMaps in Pods

The following sections describe some uses cases when consuming ConfigMap
objects in pods.

Consuming in Environment Variables

ConfigMaps can be used to populate individual environment variables or can populate environment variables
from all keys that form valid environment variable names. As an example, consider the following ConfigMaps:

To inject values into the command line, you must consume the keys you want to
use as environment variables, as in the
Consuming in Environment
Variables use case. Then you can refer to them in a container’s command using
the $(VAR_NAME) syntax.

You have a couple different options for consuming this ConfigMap in a
volume. The most basic way is to populate the volume with files where the key is
the file name and the content of the file is the value of the key:

Example: Configuring Redis

For a real-world example, you can configure Redis using a ConfigMap. To
inject Redis with the recommended configuration for using Redis as a cache, the
Redis configuration file should contain the following:

maxmemory 2mb
maxmemory-policy allkeys-lru

If your configuration file is located at example-files/redis/redis-config,
create a ConfigMap with it:

The newly-created pod has a ConfigMap volume that places the redis-config
key of the example-redis-configConfigMap into a file called
redis.conf. This volume is mounted into the /redis-master directory in
the Redis container, placing our configuration file at
/redis-master/redis.conf, which is where the image looks for the Redis
configuration file for the master.

If you oc exec into this pod and run the redis-cli tool, you can check that
the configuration was applied correctly:

Restrictions

A ConfigMap must be created before they are consumed in pods. Controllers
can be written to tolerate missing configuration data; consult individual
components configured via ConfigMap on a case-by-case basis.

ConfigMap objects reside in a project. They can only be referenced by pods
in the same project.

The Kubelet only supports use of a ConfigMap for pods it gets from the API
server. This includes any pods created using the CLI, or indirectly from a
replication controller. It does not include pods created using the
OpenShift Container Platform node’s --manifest-url flag, its --config flag, or its REST
API (these are not common ways to create pods).