Configuration Management

This example builds on Ingress Configuration by adding configuration through environment variables.

What You'll Learn

In this lesson, you'll learn:

• How to inject configuration as environment variables
• Config vs Secrets (when to use each)
• Per-environment configuration with Kustomize
• Best practices for configuration management

What Gets Created

In addition to resources from Ingress Configuration, the platform updates the Deployment to include environment variables.

What Changed

Added the spec.config section:

application.yaml

apiVersion: meta.p6m.dev/v1alpha1
kind: PlatformApplication
metadata:
  name: demo-http-echo
  namespace: demo-http-echo
  labels:
    p6m.dev/app: demo-http-echo
spec:
  config:
    LOG_LEVEL: debug
    HTTP_PORT: "8080"
    ENVIRONMENT: dev
    APP_NAME: demo-http-echo
  deployment:
    image: mendhak/http-https-echo:31
    ports:
      - port: 8080
        protocol: http
    readinessProbe:
      port: 8080
      path: /
  networking:
    ingress:
      enabled: true
      path: /
      gateway: public-open

Deploy Steps

ArgoCD

ArgoCD automatically updates to your PlatformApplication after the Platform Dispatch Action to update your .platform repository is run.

Let's use the Kinds filter to locate our Pods (spec.containers[0].env) and Deployments (spec.template.spec.containers[0].env), from there we can check the fields to verify our config was applied.

Deployment

Pod

• Check out our ArgoCD Cheat Sheet for tips on interacting with ArgoCD.
• For more information on setting up ArgoCD for Platform Applications, see the ArgoCD Deployment Tutorial.

kubectl

Apply the updated PlatformApplication

kubectl apply -f application.yaml

Check that the Deployment was updated

kubectl get deployment demo-http-echo -n demo-http-echo -o jsonpath='{.spec.template.spec.containers[0].env}'
# [{"name":"APP_NAME","value":"demo-http-echo"},{"name":"ENVIRONMENT","value":"dev"},{"name":"HTTP_PORT","value":"8080"},{"name":"LOG_LEVEL","value":"debug"}]

Check environment variables in a Pod

POD=$(kubectl get pods -n demo-http-echo -l p6m.dev/app=demo-http-echo -o jsonpath='{.items[0].metadata.name}')
kubectl exec -n demo-http-echo $POD -- env | grep -E 'LOG_LEVEL|HTTP_PORT|ENVIRONMENT|APP_NAME'
# LOG_LEVEL=debug
# HTTP_PORT=8080
# ENVIRONMENT=dev
# APP_NAME=demo-http-echo

How Config Works

The spec.config section is a simple key-value map:

• Keys become environment variable names
• Values become environment variable values (must be strings)
  • Non-string values (numbers, booleans, etc.) must be wrapped in quotes

The platform automatically:

1. Updates the Deployment specification with your config as environment variables
2. The Deployment creates a new ReplicaSet to track the updated configuration
3. Updated Pods replace the old Pods, which are cleaned up automatically

Config vs Secrets

Aspect	Config (spec.config)	Secrets (spec.secrets)
Use for	Non-sensitive settings	API keys, passwords, tokens
Stored in	Git	Cloud Secret Store
Encrypted	No	Yes (at rest)
Visible	Yes (in Git, kubectl)	No (base64 encoded)
Per-environment	Kustomize patches	Separate secret stores
Example	DATABASE_HOST	DATABASE_PASSWORD

tip

Want to know more about Best Practices? See Configuration Management - Details for more information.

Next Steps

• Secret Injection - Inject secrets from cloud secret stores

Troubleshooting

For common issues and solutions, see the Troubleshooting Guide.

Specific sections that may be helpful:

• Config Not Appearing in Pod
• Wrong Config Values
• ConfigMap Exists But Not in Pods

Cleanup

Check out the Cleanup Instructions from the Basic Deployment lesson to remove all resources created in this walkthrough.

Related Documentation

• Kubernetes ConfigMaps - Understanding ConfigMaps
• Kustomize Documentation - Kustomize overlays and patches
• 12-Factor App: Config - Configuration best practices