ConfigMaps in Kubernetes: how they work and what you should remember

PLEASE NOTE: our blog has MOVED to https://blog.flant.com/! New articles from Flant’s engineers will be posted there only. Check it out and subscribe to keep updated!

Please note that this is not a complete guide, but rather a reminder/tips collection for those who already use ConfigMap in Kubernetes or are in the middle of preparing their applications to use it.

A little background: from rsync to… Kubernetes

In the era of “classic system administration,” config files were usually stored next to the application itself (or in the repository, if you prefer). Everything was simple in delivering the code and related configs. You could even declare your rsync to be an early implementation of what we call today the continuous delivery (CD).

With the growing infrastructure, different config files were required for different environments (dev/stage/production). Applications were taught to decide which config to use while passing them as runtime arguments or as environment variables. The CD becomes even more complicated with the emergence of so useful Chef/Puppet/Ansible. Servers are getting their roles, and environments’ descriptions are no longer randomly stored as the IaC (Infrastructure as code) approach emerges.

What happened next? If software creators had managed to discern the essential advantages of Kubernetes and even accepted the need to adjust their application — and its design! — to work with the orchestrator (The 12 Factors can be painful sometimes…), then the migration followed. When the essential part was ready, a long-awaited application was up & running in K8s.

Please, read the rest here: “ConfigMaps in Kubernetes” on Palark blog.