Configuring ConfigMap

Config maps allow you to decouple configuration artifacts from image content to keep containerized applications portable. The following sections define config maps and how to create and use them.

TOC

Understanding Config Maps

Many applications require configuration by using some combination of configuration files, command-line arguments, and environment variables. In OpenShift Container Platform, these configuration artifacts are decoupled from image content 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 config map can be used to store fine-grained information like individual properties or coarse-grained information like entire configuration files or JSON blobs.

The ConfigMap 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. For example:

# my-app-config.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: my-app-config
  namespace: default
data:
  app_mode: "development"
  feature_flags: "true"
  database.properties: |-
    jdbc.url=jdbc:mysql://localhost:3306/mydb
    jdbc.username=user
    jdbc.password=password
  log_settings.json: |-
    {
      "level": "INFO",
      "format": "json"
    }

Note: You can use the binaryData field when you create a config map from a binary file, such as an image.

Configuration data can be consumed in pods in a variety of ways. A config map can be used to:

  • Populate environment variable values in containers
  • Set command-line arguments in a container
  • Populate configuration files in a volume

Users and system components can store configuration data in a config map. A config map is similar to a secret, but designed to more conveniently support working with strings that do not contain sensitive information.

Config Map Restrictions

  • A config map must be created before its contents can be consumed in pods.
  • Controllers can be written to tolerate missing configuration data. Consult individual components configured by using config maps on a case-by-case basis.
  • ConfigMap objects reside in a project.
  • They can only be referenced by pods in the same project.
  • The Kubectl only supports the use of a config map for pods it gets from the API server. This includes any pods created by using the CLI, or indirectly from a replication controller. It does not include pods created by using the OpenShift Container Platform node’s --manifest-url flag, its --config flag, or its REST API because these are not common ways to create pods.

ConfigMap vs Secret

FeatureConfigMapSecret
Data TypeNon-sensitiveSensitive (e.g., passwords)
EncodingPlaintextBase64-encoded
Use CasesConfigs, flagsPasswords, tokens

Creating a ConfigMap by using the web console

  1. Go to Container Platform.

  2. In the left sidebar, click Configuration > ConfigMap.

  3. Click Create ConfigMap.

  4. Refer to the instructions below to configure the relevant parameters.

    ParameterDescription
    EntriesRefers to key:value pairs, supporting both Add and Import methods.
    • Add: You can add configuration items one by one, or you can paste one or multiple lines of key=value pairs in the Key input area to bulk add configuration items.
    • Import: Import a text file not larger than 1M. The file name will be used as the key, and the file content will be used as the value, filled into a configuration item.
    Binary EntriesRefers to binary files not larger than 1M. The file name will be used as the key, and the file content will be used as the value, filled into a configuration item.
    Note: After creating a ConfigMap, the imported files cannot be modified.

    Example of Bulk Add Format:

    # One key=value pair per line, multiple pairs must be on separate lines, otherwise they will not be recognized correctly after pasting.
    key1=value1
    key2=value2
    key3=value3
  5. Click Create.

Creating a ConfigMap by using the CLI

kubectl create configmap app-config \
  --from-literal=APP_ENV=production \
  --from-literal=LOG_LEVEL=debug

Or from a file:

kubectl apply -f app-config.yaml -n k-1

Operations

You can click the (⋮) on the right side of the list page or click Actions in the upper right corner of the detail page to update or delete the ConfigMap as needed.

Changes to the ConfigMap will affect the workloads that reference the configuration, so please read the operation instructions in advance.

OperationsDescription
Update
  • After adding or updating a ConfigMap, any workloads that have referenced this ConfigMap (or its configuration items) through environment variables need to rebuild their Pods for the new configuration to take effect.
  • For imported binary configuration items, only key updates are supported, not value updates.
DeleteAfter deleting a ConfigMap, workloads that have referenced this ConfigMap (or its configuration items) through environment variables may be adversely affected during Pod creation if they are rebuilt and cannot find the reference source.

View, Edit and Delete by using the CLI

kubectl get configmap app-config -n k-1 -o yaml
kubectl edit configmap app-config -n k-1
kubectl delete configmap app-config -n k-1

Ways to Use a ConfigMap in a Pod

As Environment Variables

envFrom:
  - configMapRef:
      name: app-config

Each key becomes an environment variable in the container.

As Files in a Volume

volumes:
  - name: config-volume
    configMap:
      name: app-config

volumeMounts:
  - name: config-volume
    mountPath: /etc/config

Each key is a file under /etc/config, and the file content is the value.

As Individual Environment Variables

env:
  - name: APP_ENV
    valueFrom:
      configMapKeyRef:
        name: app-config
        key: APP_ENV

ConfigMap vs Secret

FeatureConfigMapSecret
Data TypeNon-sensitiveSensitive (e.g., passwords)
EncodingPlaintextBase64-encoded
Use CasesConfigs, flagsPasswords, tokens