Every application needs to be configured, and the easiest way to do so is by storing configurations in the source code. This approach has the side effect of configuration and code living and dying together, as described by the Immutable Server concept. However, we still need the flexibility to adapt configuration without recreating the application image. In fact, this recreation would be time-consuming and an antipattern for a continuous delivery approach, where the application is created once and then moves unaltered through the various stages of the deployment pipeline until it reaches production.

In such a scenario, how would we adapt an application to the different setups of development, integration, and production environments? The answer is to use external configuration data, which is different for each environment. The patterns in the following chapters are all about customizing and adapting applications with external configurations for various environments:

• Chapter 18, EnvVar Configuration, uses environment variables to store configuration data.

• Chapter 19, Configuration Resource, uses Kubernetes resources like ConfigMaps or Secrets to store configuration information.

• Chapter 20, Immutable Configuration, brings immutability to large configuration sets by putting it into containers linked to the application at runtime.

• Chapter 21, Configuration Template, is useful when large configuration files need to be managed for various environments that differ only slightly.