In this lesson, you will learn how to extract hardcoded application settings into external ConfigMap objects to keep your container images environment-agnostic.
The Problem with Hardcoding
When you bake configuration settings (like database URLs, feature flags, or log levels) directly into your container image, you violate the principle of environment parity. To change a setting, you are forced to rebuild the image, re-tag it, and re-push it to your registry. This is slow, error-prone, and prevents you from using the exact same image in your Dev, Staging, and Production environments.
The ConfigMap Solution
A ConfigMap is a Kubernetes object that stores non-sensitive configuration data as key-value pairs. By moving your settings into a ConfigMap, your application container remains "blank slate" code that simply asks Kubernetes: "What configuration should I use today?"
Here is how you define a simple ConfigMap in YAML:
apiVersion: v1
kind: ConfigMap
metadata:
name: app-settings
data:
DATABASE_URL: "db.production.svc.cluster.local"
LOG_LEVEL: "info"
Once this is applied to your cluster, you can inject these values into your Pods as environment variables. In your Deployment manifest, you reference the ConfigMap like this:
spec:
containers:
- name: my-app
image: my-app:1.0.0
envFrom:
- configMapRef:
name: app-settings
Why This Matters
By decoupling configuration from the image, your CI/CD pipeline becomes much cleaner. You build your container image once, test it, and promote that identical binary through every stage of your pipeline. When you move from Staging to Production, you don't touch the image; you simply apply a different ConfigMap specific to that environment. This ensures that what you tested is exactly what you ship, while making it trivial to update application behavior without redeploying the underlying code.
Key Takeaway: ConfigMaps allow you to maintain immutable, environment-agnostic container images by injecting configuration dynamically at runtime.