secret.code.lives=30
ui.properties: |
color.good=purple
color.bad=yellow
allow.textmode=true
how.nice.to.look=fairlyNice
```
Users that have used Secrets will find it easy to begin using ConfigMap — they’re very similar. One major difference in these APIs is that Secret values are stored as byte arrays in order to support storing binaries like SSH keys. In JSON and YAML, byte arrays are serialized as base64 encoded strings. This means that it’s not easy to tell what the content of a Secret is from looking at the serialized form. Since ConfigMap is intended to hold only configuration information and not binaries, values are stored as strings, and thus are readable in the serialized form.
We want creating ConfigMaps to be as flexible as storing data in them. To create a ConfigMap object, we’ve added a kubectl command called `kubectl create configmap` that offers three different ways to specify key-value pairs:
- Specify literal keys and value
- Specify an individual file
- Specify a directory to create keys for each file
These different options can be mixed, matched, and repeated within a single command:
```
$ kubectl create configmap my-config \
--from-literal=literal-key=literal-value \
--from-file=ui.properties \
--from=file=path/to/config/dir
```
Consuming ConfigMaps is simple and will also be familiar to users of Secrets. Here’s an example of a Deployment that uses the ConfigMap above to run an imaginary game server:
```
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: configmap-example-deployment
labels:
name: configmap-example-deployment
spec:
replicas: 1
selector:
matchLabels:
name: configmap-example
template:
metadata:
labels:
name: configmap-example
spec:
containers:
- name: game-container
image: imaginarygame
command: ["game-server", "--config-dir=/etc/game/cfg"]
env:
# consume the property-like keys in environment variables
- name: GAME\_PROPERTIES\_NAME
valueFrom: