This documentation is for a release that is no longer maintained
See documentation for the latest supported version 3 or the latest supported version 4.이 콘텐츠는 선택한 언어로 제공되지 않습니다.
Chapter 18. ConfigMaps
18.1. 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 Enterprise. 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.
For example:
Example 18.1. ConfigMap Object Definition
- 1
- Contains the configuration data.
Configuration data can be consumed in pods in a variety of ways. A ConfigMap
can be used to:
- Populate the value of environment variables.
- Set command-line arguments in a container.
- Populate configuration files in a volume.
Both users and system components may store configuration data in a ConfigMap
.
18.2. Creating ConfigMaps 링크 복사링크가 클립보드에 복사되었습니다!
You can use the following command to create a ConfigMap
easily from directories, specific files, or literal values:
oc create configmap <configmap_name> [options]
$ oc create configmap <configmap_name> [options]
The following sections cover the different ways you can create a ConfigMap
.
18.2.1. Creating from Directories 링크 복사링크가 클립보드에 복사되었습니다!
Consider a directory with some files that already contain the data with which you want to populate a ConfigMap
:
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/
$ 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.
For example, the above command creates the following ConfigMap
:
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:
18.2.2. Creating from Files 링크 복사링크가 클립보드에 복사되었습니다!
You can also pass the --from-file
option with a specific file, and pass it multiple times to the CLI. The following yields equivalent results to the Creating from Directories example:
Create the
ConfigMap
specifying a specific file:oc create configmap game-config-2 \ --from-file=example-files/game.properties \ --from-file=example-files/ui.properties
$ oc create configmap game-config-2 \ --from-file=example-files/game.properties \ --from-file=example-files/ui.properties
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Verify the results:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
You can also set the key to use for an individual file with the --from-file
option by passing an expression of key=value
. For example:
Create the
ConfigMap
specifying a key-value pair:oc create configmap game-config-3 \ --from-file=game-special-key=example-files/game.properties
$ oc create configmap game-config-3 \ --from-file=game-special-key=example-files/game.properties
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Verify the results:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
18.2.3. Creating from Literal Values 링크 복사링크가 클립보드에 복사되었습니다!
You can also supply literal values for a ConfigMap
. The --from-literal
option takes a key=value
syntax that allows literal values to be supplied directly on the command line:
Create the
ConfigMap
specifying a literal value:oc create configmap special-config \ --from-literal=special.how=very \ --from-literal=special.type=charm
$ oc create configmap special-config \ --from-literal=special.how=very \ --from-literal=special.type=charm
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Verify the results:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
18.3. Use Cases: Consuming ConfigMaps in Pods 링크 복사링크가 클립보드에 복사되었습니다!
The following sections describe some uses cases when consuming ConfigMap
objects in pods.
18.3.1. Consuming in Environment Variables 링크 복사링크가 클립보드에 복사되었습니다!
A ConfigMap
can be used to populate the value of command line arguments. For example, consider the following ConfigMap
:
You can consume the keys of this ConfigMap
in a pod using configMapKeyRef
sections:
When this pod is run, its output will include the following lines:
SPECIAL_LEVEL_KEY=very SPECIAL_TYPE_KEY=charm
SPECIAL_LEVEL_KEY=very
SPECIAL_TYPE_KEY=charm
18.3.2. Setting Command-line Arguments 링크 복사링크가 클립보드에 복사되었습니다!
A ConfigMap
can also be used to set the value of the command or arguments in a container. This is accomplished using the Kubernetes substitution syntax $(VAR_NAME)
. Consider the following ConfigMap
:
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.
When this pod is run, the output from the test-container container will be:
very charm
very charm
18.3.3. Consuming in Volumes 링크 복사링크가 클립보드에 복사되었습니다!
A ConfigMap
can also be consumed in volumes. Returning again to the following example ConfigMap
:
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:
When this pod is run, the output will be:
very
very
You can also control the paths within the volume where ConfigMap
keys are projected:
When this pod is run, the output will be:
very
very
18.4. 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
maxmemory 2mb
maxmemory-policy allkeys-lru
If your configuration file is located at example-files/redis/redis-config, create a ConfigMap
with it:
Create the
ConfigMap
specifying the configuration file:oc create configmap example-redis-config \ --from-file=example-files/redis/redis-config
$ oc create configmap example-redis-config \ --from-file=example-files/redis/redis-config
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Verify the results:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Now, create a pod that uses this ConfigMap
:
Create a pod definition like the following and save it to a file, for example redis-pod.yaml:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Create the pod:
oc create -f redis-pod.yaml
$ oc create -f redis-pod.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
The newly-created pod has a ConfigMap
volume that places the redis-config key of the example-redis-config ConfigMap
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:
18.5. 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 Enterprise node’s --manifest-url
flag, its --config
flag, or its REST API (these are not common ways to create pods).