If you are not familiar with the oc command, refer to OpenShift - Getting Started with the oc command.

Config Maps are used to:

• mount configuration files in a container
• create environment variables in a container
• create command line option arguments in a container

Secrets are similar, used to create variables that contain encoded data (e.g. passwords). In this way, if a change is needed to a configuration file, variable, or command line option argument, you just need to update the config map or secret as opposed to having to make the change to your applications or deployments.

The oc get configmaps command can be used to list the config maps that have been created in the currently selected project.

~]$ oc get configmaps
NAME                         DATA      AGE
my-variables                 1         44d
my-command-line-arguments    1         44d
my-configuration-files       1         44d

The --output yaml or --output json options can be used to display the YAML or JSON details of a config map. In this example, my-variables contains variables (user: john.doe and role: admin).

~]$ oc get configmap my-variables --output yaml
apiVersion: v1
data:
  user: john.doe
  role: admin
kind: ConfigMap

And my-command-line-arguments contains env: staging.

~]$ oc get configmap my-command-line-arguments --output yaml
apiVersion: v1
data:
  env: staging
kind: ConfigMap

And perhaps my-configuration-files contains something like this.

~]$ oc get configmap my-configuration-files --output yaml
apiVersion: v1
data:
  server.xml: |
    <?xml version='1.0' encoding='utf-8'?>
    <Server port="8080" />
kind: ConfigMap

Let's say you have a deployment named my-deployment.

~]# oc get deployments
NAME            READY   UP-TO-DATE   AVAILABLE   AGE
my-deployment   1/1     1            1           8d

The oc edit deployment command can be used to update the deployment YAML.

It is important to recognize that when mounting a Config Map that contains a file as a Volume Mount, the file will be read only, meaning the file cannot be written to. If you need to be able to write to the file, it probably makes more sense to use mount a Persistent Volume Claim in the container.

apiVersion: v1
kind: Deployment
spec:
  template:
    spec:
      containers:
      - env:

        - name: vars <- this will be the name of the variable in the container
          valueFrom:
            configMapRef:
              name: my-variables <- must match config map name

        - name: environment <- this will be the name of the variable in the container
          valueFrom:
            configMapRef:
              name: my-command-line-arguments <- must match config map name

        name: my-container

        volumeMounts:
        - name: configuration-files <- must match volume name
          mountPath: /data/conf/server.xml
          subPath: server.xml <- If subPath is not used, server.xml will be mounted as a directory. subPath must be used to mount server.xml as a file.

      volumes:
      - name: configuration-files <- something unique
        configMap:
          name: my-configuration-files <- must match config map name

Or, configMapKeyRef can be used instead of configMapRef if you only want to use certain keys in the config map.

apiVersion: v1
kind: Deployment
spec:
  template:
    spec:
      containers:
      - env:

        - name: username <- this will be the name of the variable in the container
          valueFrom:
            configMapKeyRef:
              key: user <- must match config map key
              name: my-variables <- must match config map name

        - name: environment <- this will be the name of the variable in the container
          valueFrom:
            configMapKeyRef:
              key: env <- must match config map key
              name: my-command-line-arguments <- must match config map name

Or, envFrom can be used instead of env. In this example, since the my-variables config map contains "user: john.doe: and "role: admin" these variables will be available in the container.

apiVersion: v1
kind: Deployment
spec:
  replicas: 1
  template:
    spec:
      containers:
      - envFrom: 
        - configMapRef:
            name: my-variables <- must match config map name

A new pod should immediately be created after the oc edit command has been completed, and the oc describe pod command can be used to see that the pod is now has the environment variables from the my-variables config map and also has server-xml-file config map mounted.

~]$ oc describe pod my-app-65rbl
Containers:
  my-container:
    Environment:
      user: john.doe
      admin: admin
      env: staging
    Mounts:
      /data/conf/server.xml from configuration-files (ro)
Volumes: 
  configuration-files:
    Type:        Config Map (a volume populated by a Config Map)
    Name:        my-configuration-files
    Optional:    false

The oc exec command can be used to now see that the environment varibles, command line option arguments, and configuration files (server.xml) file are present in the container.

~]$ oc exec pod/my-app-8x2nz -- env
user=john.doe
role=admin
environment=staging

~]$ oc exec pod/my-app-8x2nz -- ls -l /data/conf
-rw-r--r--. 1 root  1000820000   6605 Dec 30 03:24 server.xml

In this example, since command line option argument environment is set to staging, $environment can be used in the container as a command line argument.

~]$ oc exec pod/my-app-8x2nz -- example.sh env=$environment