Probably one of the most annoying issues one can make for themselves is things hardcoded into container itself. Because it's a matter of when, not if, that you will have an urgent need to change something, or deploy more than one copy, and building a new container version will be either too slow, or slow you down enough to make you irritated.

Parameterizing your containers allows you operational flexibility you'll end up loving, especially with ConfigMaps/Secrets mounted as environment variables.

If you have software that needs configuration file and you don't have resources to change that at the moment, a pretty good solution is to use envsubst as part of your entrypoint script in Dockerfile .

Parameterization is also core concept of 12-factor apps, which are easier to operate in cloud native way, as they automatically pull necessary configuration from their environment. By parameterizing the whole container, often with a script as part of your Docker entrypoint, we can bring configuration from environment even to applications that don't support it natively.

envsubst is part of gettext utilities (and thus reasonably small dependency on your containers) and allows shell-style replacement of variables in files.

# As part of your entrypoint script: envsubst < config.template > config # Will replace shell variable references in ${VAR} style with variables # taken from environment

This can be utilized with envFrom in your pod specs this way:

--- apiVersion: v1 kind: ConfigMap metadata: name: dev-config data: ENV: development DB: dev.db --- apiVersion: apps/v1 kind: Deployment metadata: name: dev-deployment spec: replicas: 1 selector: matchLabels: app: my-app env: dev template: metadata: labels: app: my-app env: dev spec: containers: - name: app image: mycorp/my-app:0.0.1 envFrom: - configMapRef: name: dev-config

Above deployment will automatically have ENV and DB environment variables set from dev-config ConfigMap . Since ConfigMaps are namespace-scoped, you can even use standard name and use namespaces to separate them - for example, "dev" namespace might have a configmap that sets defaults specific to dev environment, while the YAML files for deployment remain the same.