Kubernetes Patterns Environment Variable-Based Configuration: Difference between revisions
Jump to navigation
Jump to search
| (6 intermediate revisions by the same user not shown) | |||
| Line 12: | Line 12: | ||
* Dockerfile [[Dockerfile#ENV|<code>ENV</code> directive]]. | * Dockerfile [[Dockerfile#ENV|<code>ENV</code> directive]]. | ||
* As [[Dockerfile#Env_Override|command line override]] when running the container. | * As [[Dockerfile#Env_Override|command line override]] when running the container. | ||
* As hardcoded environment variable values in Kubernetes Pod | * As hardcoded environment variable values in Kubernetes Pod manifest files with <code>[[Kubernetes_Pod_Manifest#env|spec.containers[*].env]]</code>, or their corresponding representation in Deployment or ReplicaSet manifest files. | ||
* As environment variable values projected into pods by [[Kubernetes_Cluster_Configuration_Concepts#As_Environment_Variables|ConfigMaps]] and [[Kubernetes_Cluster_Configuration_Concepts#Secrets_Projected_as_Environment_Variables|Secrets]]. | |||
'''Disadvantages''': | |||
* Environment variables become unwieldy for large amounts of configuration. | |||
* Environment variables are not secure, the configuration easily surfaces in the logs. | |||
* Because environment variables can be set at multiple levels, configuration can become fragmented. It could be hard to track for a given environment variable where it is set. | |||
* Environment variables can only be set before the application starts. However, this may not be such a big problem, as we tend to favor immutable configuration. | |||
Latest revision as of 20:20, 28 February 2024
External
Internal
Overview
Environment variables are universally supported and suited for configuration values that are small in size. Every operating systems allows definition of environment variable, and every programming language allows easy access to these environment variables.
As long as the application is coded to expect configuration as environment variables, the actual values of those environment variables can be provided in different layers:
- Dockerfile
ENVdirective. - As command line override when running the container.
- As hardcoded environment variable values in Kubernetes Pod manifest files with
spec.containers[*].env, or their corresponding representation in Deployment or ReplicaSet manifest files. - As environment variable values projected into pods by ConfigMaps and Secrets.
Disadvantages:
- Environment variables become unwieldy for large amounts of configuration.
- Environment variables are not secure, the configuration easily surfaces in the logs.
- Because environment variables can be set at multiple levels, configuration can become fragmented. It could be hard to track for a given environment variable where it is set.
- Environment variables can only be set before the application starts. However, this may not be such a big problem, as we tend to favor immutable configuration.