OpenShift ConfigMaps: Ultimate Solution for Microservices Management

A ConfigMap is a Kubernetes component available in Openshift that allows application developers to store configuration and metadata information used by the application centrally inside the cluster. Since ConfigMaps are native to Kubernetes this can be leveraged on all managed Kubernetes in the cloud as well as On-Premise and Hybrid cloud environments.

Before we start looking into how to do things the right way, let’s look at common problems that can be avoided by using ConfigMaps for configuration management.

Longer Code Deployment Cycles:

Embedding configuration inside the code or properties/configuration inside the code leads to the creation and management of several builds for each environment.
Database usernames and passwords, hostnames, etc differ between environments and need to be changed for each environment. Rebuilding the same code for each environment adds to overall costs and effort and decreases efficiency.

Security

Developers accidentally pushing credentials to GitHub or any other source control tools is one of the most common security incidents. Moving configuration values out of the code is a great way to avoid this from happening in the first place.

Configuration Reusability

A configuration change in a microservice-based application running 100+ microservices is a tedious task. Each microservice code needs to be changed to use the new configuration value and then would need to be deployed. A small change in configuration will take a long time to be reflected across services because of the longer code deployment cycles mentioned in #1.

Easier Debugging

When multiple microservice is running independently with their own set of configurations embedded inside. It makes it difficult for developers to identify any faults in configuration.

Let’s look at some of the reasons how ConfigMaps makes configuration management easier in a multi-environment openshift cluster.

Dynamic configuration: ConfigMaps allows configuration to be changed dynamically, and configuration stored on configMaps is created and updated without having to do a build and redeployment of the application. This allows for more flexibility in testing and reduces the overall build and deployment time.
Security: Since the configuration is moved out of the code and build process and stored at the cluster level. Only specific people with access to Openshift Dashboard and namespaces are allowed access to the ConfigMap objects and access to each individual configMaps can be fine-grained. This also avoids the accidental push and storage of credentials in code repositories.
Environment-Specific Configuration: ConfigMaps can be used to store environment-specific configuration data. For example, you can use different ConfigMaps for development, staging, and production environments. They can also be separated using a namespace. configured at the environment level, applications can use configuration values fit for that environment. A configuration like max thread or heap size can be kept low for environments like development and can be higher for production-level systems.
ConfigMaps can be easily shared between different parts of your application deployments or between different applications, making it easier to reuse configuration data.
ConfigMaps can be easily updated and scaled as your application grows, making it easier to manage your configuration data as your application evolves over time.
Single Point of Reference for all Configuration: Since all of our configurations is stored in a single place in the cluster it is easier to get an idea of what kind of configuration each application is using and serves as a reference during debugging.
Integration with Openshift: ConfigMaps are native to Kubernetes but have a first-hand integration with Openshift, they are available to use and change via the Openshift Dashboard.