Introduction to ConfigMap in Kubernetes 1.2 for Configuration Management

--- title: " Configuration management with Containers " date: 2016-04-04 slug: configuration-management-with-containers url: /blog/2016/04/Configuration-Management-With-Containers author: > Paul Morie (Red Hat) --- _**Editor's note:** this is our seventh post in a [series of in-depth posts](/blog/2016/03/five-days-of-kubernetes-12) on what's new in Kubernetes 1.2_ A [good practice](http://12factor.net/config) when writing applications is to separate application code from configuration. We want to enable application authors to easily employ this pattern within Kubernetes. While the Secrets API allows separating information like credentials and keys from an application, no object existed in the past for ordinary, non-secret configuration. In [Kubernetes 1.2](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG.md/#v120), we've added a new API resource called ConfigMap to handle this type of configuration data. #### **The basics of ConfigMap** The ConfigMap API is simple conceptually. From a data perspective, the ConfigMap type is just a set of key-value pairs. Applications are configured in different ways, so we need to be flexible about how we let users store and consume configuration data. There are three ways to consume a ConfigMap in a pod: - Command line arguments - Environment variables - Files in a volume These different methods lend themselves to different ways of modeling the data being consumed. To be as flexible as possible, we made ConfigMap hold both fine- and/or coarse-grained data. Further, because applications read configuration settings from both environment variables and files containing configuration data, we built ConfigMap to support either method of access. Let’s take a look at an example ConfigMap that contains both types of configuration: ``` apiVersion: v1 kind: ConfigMap metadata: Name: example-configmap data: # property-like keys game-properties-file-name: game.properties ui-properties-file-name: ui.properties # file-like keys game.properties: | enemies=aliens lives=3 enemies.cheat=true enemies.cheat.level=noGoodRotten secret.code.passphrase=UUDDLRLRBABAS secret.code.allowed=true 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

This blog post introduces ConfigMap, a new API resource in Kubernetes 1.2 designed to manage non-secret configuration data separately from application code. It explains the basics of ConfigMap, including how it stores key-value pairs and the different ways to consume a ConfigMap in a pod (command-line arguments, environment variables, and files in a volume). The post provides an example ConfigMap containing both property-like and file-like configurations, highlighting the flexibility of the ConfigMap API. It also mentions the similarities and differences between ConfigMap and Secrets, focusing on the storage of values as strings in ConfigMap for readability. Finally, it introduces the `kubectl create configmap` command, offering various methods to specify key-value pairs when creating ConfigMaps.