OpenShift ConfigMaps for Spring Boot

Learn how to use ConfigMaps in OpenShift to externalize Spring Boot configuration, inject environment variables, mount configuration files, and manage application settings without rebuilding container images.

Introduction

In enterprise applications, configuration changes frequently while application code changes less often.

For example:

Database URL changes
Kafka brokers change
Feature flags change
Logging levels change
API endpoints change

If these values are hardcoded inside a Spring Boot application, every configuration change requires:

Updating source code
Rebuilding the application
Creating a new container image
Redeploying the application

This is not practical.

OpenShift solves this problem using ConfigMaps.

ConfigMaps allow you to externalize configuration from your application so that configuration changes can be managed independently of your application code.

Learning Objectives

By the end of this article, you will understand:

What is a ConfigMap?
Why ConfigMaps are needed
ConfigMap architecture
Environment variables
Mounting configuration files
Spring Boot integration
Updating configurations
Enterprise use cases
Best practices

Why Do We Need ConfigMaps?

Imagine a Spring Boot application with hardcoded values.

String dbUrl = "jdbc:postgresql://prod-db:5432/payment";

Problems:

Different environments require different values.
Requires rebuilding the application.
Difficult to maintain.
Violates cloud-native principles.

Configuration Before ConfigMap

flowchart LR
    Source[Source Code]
    --> Build[Maven Build]
    --> Image[Docker Image]
    --> Deployment[Deployment]

Any configuration change requires rebuilding the image.

Configuration With ConfigMap

flowchart LR
    ConfigMap[ConfigMap]
    --> Deployment

    Deployment
    --> Pod

    Pod
    --> SpringBoot[Spring Boot Application]

Configuration is managed separately from the application.

What is a ConfigMap?

A ConfigMap is an OpenShift/Kubernetes resource used to store:

Configuration values
Environment variables
Property files
YAML files
JSON files
XML files

ConfigMaps should never store passwords or sensitive information.

ConfigMap Architecture

flowchart TD
    ConfigMap

    --> Deployment

    Deployment

    --> Pod1[Spring Boot Pod 1]

    Deployment

    --> Pod2[Spring Boot Pod 2]

    Pod1 --> Application1[Spring Boot]

    Pod2 --> Application2[Spring Boot]

Multiple Pods can consume the same ConfigMap.

Real-World Example

Different environments require different configuration.

Development

Database
dev-db

Kafka
dev-kafka

API URL
dev-api

Production

Database
prod-db

Kafka
prod-kafka

API URL
prod-api

Only the ConfigMap changes.

Create ConfigMap

apiVersion: v1
kind: ConfigMap

metadata:
  name: payment-config

data:

  DB_HOST: postgres

  DB_PORT: "5432"

  KAFKA_SERVER: kafka:9092

  LOG_LEVEL: INFO

Create:

oc apply -f configmap.yaml

Verify ConfigMap

oc get configmaps

Example:

payment-config

Describe:

oc describe configmap payment-config

ConfigMap as Environment Variables

env:

- name: DB_HOST
  valueFrom:
    configMapKeyRef:
      name: payment-config
      key: DB_HOST

- name: DB_PORT
  valueFrom:
    configMapKeyRef:
      name: payment-config
      key: DB_PORT

Environment Variable Flow

flowchart LR
    ConfigMap

    --> EnvironmentVariable[Environment Variables]

    --> SpringBoot[Spring Boot Application]

Access in Spring Boot

spring.datasource.url=jdbc:postgresql://${DB_HOST}:${DB_PORT}/payment

Spring Boot automatically reads environment variables.

Using @Value

@Value("${DB_HOST}")
private String databaseHost;

Using ConfigurationProperties

@ConfigurationProperties(prefix = "app")
public class AppProperties {

    private String name;

    private String version;

}

Recommended for large applications.

ConfigMap as Files

Sometimes applications require configuration files instead of environment variables.

flowchart TD
    ConfigMap

    --> MountedFile

    --> SpringBoot

ConfigMap Example

apiVersion: v1
kind: ConfigMap

metadata:
  name: app-config

data:

  application.properties: |

    server.port=8080

    logging.level.root=INFO

    app.name=Payment Service

Mount ConfigMap

volumeMounts:

- name: config-volume

  mountPath: /config

volumes:

- name: config-volume

  configMap:

    name: app-config

Spring Boot reads configuration directly from mounted files.

Spring Boot External Configuration

spring.config.additional-location=file:/config/

Spring Boot loads configuration from the mounted ConfigMap.

Enterprise Banking Example

flowchart LR
    CONFIG["ConfigMap"]

    PAYMENT["Payment Service"]
    CUSTOMER["Customer Service"]
    NOTIFY["Notification Service"]

    CONFIG --> PAYMENT
    CONFIG --> CUSTOMER
    CONFIG --> NOTIFY

Each service can have its own ConfigMap.

Feature Flags

ConfigMaps are commonly used for feature toggles.

Example:

FEATURE_PAYMENT_V2: "true"

FEATURE_REWARDS: "false"

Spring Boot:

@Value("${FEATURE_PAYMENT_V2}")
private boolean paymentV2;

No application rebuild required.

Logging Configuration

LOG_LEVEL: DEBUG

Spring Boot:

logging.level.root=${LOG_LEVEL}

Different environments can have different logging levels.

Update ConfigMap

oc edit configmap payment-config

oc apply -f configmap.yaml

Some applications require a Pod restart to pick up changes.

Configuration Flow

flowchart LR
    Developer

    --> ConfigMap

    --> Deployment

    --> Pod

    --> SpringBoot

Verify Environment Variables

Open Pod terminal.

oc rsh payment-api-xxxxx

Check variables.

env

Output:

DB_HOST=postgres

DB_PORT=5432

Enterprise Architecture

flowchart TD
    CONFIG["ConfigMap"]

    API["API Gateway"]
    PAYMENT["Payment Service"]
    CUSTOMER["Customer Service"]
    NOTIFY["Notification Service"]

    POSTGRES[("PostgreSQL")]
    KAFKA[("Kafka")]

    CONFIG --> API
    CONFIG --> PAYMENT
    CONFIG --> CUSTOMER
    CONFIG --> NOTIFY

    PAYMENT --> POSTGRES
    NOTIFY --> KAFKA

Each microservice has independent configuration.

ConfigMap vs Secrets

ConfigMap	Secret
Public configuration	Sensitive information
Database Host	Database Password
Kafka Server	API Keys
Logging Level	Certificates
Feature Flags	Tokens

Rule:

Configuration → ConfigMap

Credentials → Secret

Best Practices

Keep configuration outside application code.
Use one ConfigMap per microservice.
Store ConfigMaps in Git.
Use meaningful names.
Separate configurations for Dev, QA, and Production.
Avoid storing passwords.
Use Spring Boot external configuration.
Version control configuration files.

Common Mistakes

❌ Storing passwords inside ConfigMaps.

❌ Hardcoding configuration.

❌ Sharing one ConfigMap across unrelated applications.

❌ Using ConfigMaps for certificates.

❌ Forgetting to restart Pods after updates (if required).

Advantages

No application rebuild
Environment-specific configuration
Easy maintenance
Cloud-native design
Better portability
GitOps friendly
Simplifies deployments
Improves developer productivity

Summary

ConfigMaps are the recommended way to externalize configuration in OpenShift.

Key takeaways:

ConfigMaps separate configuration from application code.
Spring Boot can consume ConfigMaps as environment variables or mounted files.
ConfigMaps simplify deployments across multiple environments.
They should never contain sensitive information.
ConfigMaps are essential for cloud-native and microservice architectures.

Interview Questions

What is a ConfigMap?
Why are ConfigMaps important?
How do ConfigMaps differ from Secrets?
How can Spring Boot read ConfigMap values?
Can ConfigMaps be mounted as files?
Do ConfigMap updates automatically refresh running Pods?
Why shouldn't passwords be stored in ConfigMaps?
What are feature flags?
What is the benefit of externalized configuration?
What are ConfigMap best practices?